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1.0  INTRODUCTION 


Air  Force  logistics  decision-makers  are  faced  with  declining  manpower  and  shrinking 
material  budgets,  as  well  as  demand  for  flexible,  cost-effective  operations.  Reduced 
business-cycle  times  and  improved  process  efficiencies  are  becoming  increasingly 
critical.  In  addition,  logistics  units  such  as  depots  are  facing  increased  competition  from 
commercial  firms  for  aircraft  repair  and  maintenance  business.  One  response  to  this 
dilemma  is  embodied  in  the  concept  of  “Lean  Logistics”  with  its  associated  components 
such  as  two-level  maintenance  and  just-in-time  inventory  control.  However,  past 
experience  suggests  that  while  significant  improvements  are  sometimes  achievable, 
improvements  require  detailed  analysis  and  planning.  Potential  process  changes  should 
be  carefully  evaluated  by  groups  of  key  stakeholders.  Thus,  the  means  to  obtain  effective 
involvement  during  process  analysis  is  essential.  The  Depot  Operations  Modeling 
Environment  (DOME)  system  is  designed  to  support  such  an  effort. 

The  goal  of  the  DOME  system  is  to  aid  in  the  design  and  modeling  of  Air  Force  logistics 
processes  between  dispersed  groups  and  installations.  It  provides  new  communications 
capabilities  to  improve  the  discussion  and  refinement  of  process  models  and  to  improve 
the  coordination  of  their  implementation.  It  also  includes  state  of  the  art  collaborative 
process  modeling  tools  and  methods.  The  system  relies  heavily  on  an  existing 
commercial-off-the-shelf  (COTS)  product,  GroupSystems®,  as  an  underlying 
infra  structure.  Many  of  the  tools  developed  for  the  DOME  project  extend  the  capabilities 
of  the  COTS  tool  and  offer  greater  functionality. 

The  DOME  effort  is  characterized  by  four  major  components:  1)  installation  of  a 
collaborative  environment  establishing  connectivity  between  Air  Force  depots  and  wing 
customers  (GroupSystems  running  distributed  on  a  Citrix  WinFrame®  server  and  video¬ 
teleconferencing),  2)  development  of  distributed  process  modeling  tools,  3)  development 
of  artificial  intelligence  facilitation  tools  and  methods,  and  4)  development  of  templates 
and  wizards  (ActionPlanner  and  SenseMaker)  to  facilitate  the  use  of  collaborative 
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software  tools  in  strategic  planning  and  analysis.  In  addition  to  the  software  tools 
developed,  a  methodology  for  using  the  tools  has  also  been  developed  and  tested. 

The  DOME  system  has  been  successfully  installed  and  demonstrated  at  the  Wamer- 
Robins  ALC,  Robins  AFB,  Georgia  and  the  366th  Wing  at  Mountain  Home  AFB,  Idaho. 
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2.0  DOME  ENVIRONMENT 


2.1  DOME  System  Description 

The  DOME  system  has  been  designed  to  provide  an  easy  to  manage  setting  for 
distributed  collaboration.  The  basic  components  are  a  Citrix  WinFrame  Server,  a  Web 
Server,  client  computers,  and  various  software  components. 

Citrix  WinFrame  Server 

The  Citrix  WinFrame  Server  is  the  key  component  in  running  distributed  GroupSystems 
sessions.  The  WinFrame  software  allows  users  to  access  the  server  via  the  Internet, 
providing  a  mechanism  to  use  GroupSystems  in  a  distributed  way.  This  server  should  be 
a  Pentium  II  class  computer  running  Citrix  WinFrame  Server  1.7.  The  WinFrame 
software  requires  16  megabytes  of  memory  for  the  operating  system  and  an  additional  8 
megabytes  of  memory  for  each  user.  The  total  amount  of  memory  will  depend  upon  the 
number  of  WinFrame  clients  desired.  The  server  should  have  a  minimum  of  4  gigabytes 
hard  disk  storage. 

Web  Server 

The  Web  Server  is  used  to  house  the  Collaborative  Process  Modeler.  This  server  should 
be  a  Pentium  II  class  computer  running  Microsoft®  Windows  NT®  Server  4.0  and  NT 
Server's  built-in  Web  server  software,  Internet  Information  Server  4.0  (IIS).  The 
minimum  memory  required  for  the  server  is  64  megabytes  with  at  least  4  gigabytes  of 
hard  disk  storage.  Though  other  server  software  can  be  used  for  a  Web  Server,  the 
DOME  experience  has  shown  that  NT  Server  4.0  is  very  reliable  and  easy  to  maintain. 
Additionally,  the  IIS  software  makes  it  easy  to  share  documents  and  information  across 
the  Internet  and  is  the  fastest  Web  server  for  Windows  NT  Server.  This  combination  of 
Web  and  operating  system  services  makes  it  possible  to  deploy  scalable  and  reliable 
Web-based  applications. 

Client  Computers 

The  client  computers,  those  used  in  the  collaborative  meeting  rooms  or  at  individual 
desktops,  should  be  able  to  connect  to  the  Internet  and  run  Microsoft  Internet  Explorer 
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software.  This  provides  a  wide-range  of  flexibility  for  installations  with  older  hardware 
configurations  (e.g.,  486  class  machines  running  Windows  3.x).  The  recommended  client 
computer  is  a  Pentium  II  class  computer  running  Microsoft  Windows  95/98  or  NT 
Workstation  4.0,  at  least  32  megabytes  of  memory,  and  2  gigabytes  of  hard  disk  storage. 

Software 

Each  client  computer  should  have  Microsoft  Internet  Explorer  4.01  SP1  software 
installed.  This  is  the  only  Internet  browser  supported  by  the  Collaborative  Process 
Modeler  tool.  GroupSystems  for  Windows  1.1,  from  Ventana  Corporation,  should  be 
installed  on  the  WinFrame  Server.  Additionally,  those  computers  performing  desktop 
videoconferencing  should  have  the  appropriate  drivers  and  software  installed,  depending 
on  the  type  of  desktop  camera  being  used. 

2.2  DOME  Methodology 

The  objective  of  the  Depot  Operations  Modeling  Environment  (DOME)  project  was  to 
develop  and  demonstrate  distributed  groupware  technologies  that  support 
anytime/anyplace  planning  and  decision  making  within  and  between  the  logistics  support 
groups  at  the  wing  and  depot.  To  this  end,  a  methodology  was  developed  to  guide  the 
application  of  DOME  to  AF  logistical  processes.  Collaborative  tools  and  technologies 
were  necessary  to  involve  potential  users  in  decision  making  and  problem  definition 
activities.  Given  the  complexity  of  logistics,  all  these  capabilities  were  attained  through 
the  application  of  effective  collaborative  (DOME)  methodologies  and  tools.  The 
methodology  involves  technology  developed  at  the  CMI  which  is  a  network-based  set  of 
flexible  software  tools  which  incorporate  basic  problem-solving  techniques  such  as 
brainstorming,  idea  organization,  voting,  issue  analysis,  policy  formation,  prioritization 
of  ideas,  and  stakeholder  identification.  Electronic  communications  allow  all  group 
members,  whether  or  not  they  are  distributed,  to  contribute  to  the  group’s  task  both 
simultaneously  and  asynchronously.  The  approach  integrated  current  methodologies  in 
use  at  the  University  of  Arizona  and  elsewhere  into  a  single,  comprehensive  DOME 
methodology: 
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1 .  Group-enabled  analysis  of  business  process  and  context 

2.  Group-enabled  monitoring  of  implementation  outcomes 

3 .  Collaborative  strategic  planning 

4.  Development  of  advanced  facilitation  tools  and  methods 

Field  studies  were  conducted  as  part  of  this  research  and  are  described  in  the  appendices 
of  this  report.  An  Air  Force  base  in  Idaho  and  a  depot  in  Georgia  were  synchronously 
connected  using  audio  teleconferencing,  video  conferencing  and  data  exchange  to 
develop  a  process  model  to  improve  aircraft  repair.  Next,  an  Air  Force  base,  depot, 
headquarters,  and  project  managers  located  in  five  different  states  collaborated 
asynchronously  using  data  and  telephone  exchanges  to  verify  the  process  model  created 
in  the  previous  study. 

Collaborative  meeting  technology  was  also  used  to  expedite  and  enhance  the  Air  Force 
strategic  planning  process.  Strategic  planning  is  seen  as  an  essential  part  of  establishing 
an  organization’s  direction.  Due  to  the  Government  Performance  and  Results  Act 
(GPRA)  mandate  that  all  government  organizations  use  strategic  planning,  more 
emphasis  will  be  directed  toward  the  topic  as  organizations  search  on  the  best  methods  to 
incorporate  it.  Although  strategic  planning  is  utilized  throughout  the  Air  Force  today  in 
various  forms,  sessions  can  become  time  consuming  without  clear  direction  or  structure 
to  the  planning.  Computer-supported  strategic  planning  is  one  avenue  of  making 
effective  use  of  technology  to  better  the  strategic  planning  process.  This  research 
implements  a  group  support  system  (GSS)  as  a  facilitation  tool  to  improve  the  strategic 
planning  process.  Implementation  of  GroupSystems  on  the  strategic  planning  process 
was  expected  to:  (1)  improve  the  quality  of  the  strategic  plan,  (2)  reduce  time  to 
completion,  (3)  increase  satisfaction  with  the  process,  and  (4)  increase  commitment  to  the 
strategic  plans  developed. 

2.3  Feasibility  of  Multimedia  and  Other  Information  Technologies 
The  flight  line  is  a  hectic  and  complex  environment  that  requires  collaboration  between 
Flights,  across  Squadrons,  and  with  other  Air  Force  installations.  Future  AF  flight  lines 
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may  consider  using  wireless  computer,  audio,  and  video  technology  to  improve  the 
logistics  processes,  such  as  the  AFTO  107  process  used  in- the  Technology  Demonstration 
phase  of  DOME.  The  following  would  be  an  ideal  scenario  using  technology  with  the 
AFTO  107  process.  First,  a  technician  working  on  the  aircraft  would  recognize  a 
potential  AFTO  107.  Second,  the  airmen  moves  10  to  20  feet  to  a  mobile  tool  box 
imbedded  with  a  laptop  and  fills  out  a  World  Wide  Web  based  AFTO  107  with  an 
attached  digital  photograph  or  video  clip  to  provide  additional  information  on  the 
problem.  Third,  the  technician  electronically  sends  the  potential  AFTO  107  a  supervisor 
whose  digital  or  iridium  (for  global  TDY)  phone  shows  the  message.  The  supervisor 
then  reviews  the  AFTO  107  and  passes  the  TO  on  to  ACC  and  the  depot,  replies  back  to 
the  technician  for  more  information,  or  rejects  the  AFTO  107  with  explanation.  Fourth, 
when  the  depot  and  ACC  get  the  AFTO  107  an  electronic  acknowledgement  is 
automatically  sent  to  the  supervisor.  If  engineers  require  additional  information 
supervisors  can  be  contacted  via  the  same  technology  the  technical  used.  If  required  the 
supervisor,  can  go  to  the  aircraft  to  use  a  digital  video  camera  to  show  and  tell  the 
engineer  about  the  problem  in  near  real-time  over  the  web.  If  time  zones  are  an  issue,  the 
supervision  and  engine  can  send  the  digital  video  and  audio  for  asynchronous  interaction. 
The  same  type  of  interaction  can  happen  with  the  supervisor  and  the  technician  if 
required.  Finally,  the  system  updates  all  parties  on  where  an  aircraft  is  in  AFTO  1 07  via 
the  World  Wide  Web  and  the  digital  communication  system. 

Much  of  the  technology  required  to  do  make  the  above  scenario  a  reality  already  exists. 
CMI  tested  wireless  10MB  communications  systems.  The  wireless  systems  tested  were 
an  IR  and  RF-based  systems  from  JVC  Wireless  Networks  and  Clarion  Wireless  LAN 
Division  respectively. 

Infrared  (IR)  Component 

The  components  of  the  IR  system  consisted  of  two  JVC  VIPSLAN-10  OA-N101U 
Stations  (arranged  in  a  station-station  configuration)  and  two  JVC  VIPSLAN-10  OA- 
TU10U  T- Adapters  and  two  9  Vdc  power  adapters. 
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The  OA-N101U  Stations  are  able  to,  once  mounted,  search  for  each  other  and  establish  a 
10  Mbps  IR  communications  channel  that  is  then  easily  interfaced  to  an  Ethernet  10 
Base-T  hub  or  a  computer.  The  range  of  separation  between  two  stations  can  be  up  to 
20m.  The  OA-TU10U  T- Adapter  provides  a  simultaneous  interface  of  a  signal  line  and 
power  to  the  station  unit. 

Radio  Frequency  (RF)  Component 

The  components  of  the  RF  system  consisted  of  the  following: 

a.  Two  Clarion  M 1 0  JX-4000F-C  RF  transceivers; 

b.  Two  6  VDE  power  adapters; 

c.  Two  Hyperlink  antennas;  and 

d.  Two  smaller  omni  directional  antennas. 

The  JX-4000F-C  is  a  wireless  transceiver  that  provides  a  reliable,  secure  and  long  range 
10  Mbps  burst  data  rate  to  support  wireless  connections  in  IEEE  802.3  and  Ethernet  II 
(TCP/IP)  LAN.  The  transceivers  are  also  easily  interfaced  to  an  Ethernet  10  Base-T  hub. 

Installation 

The  wireless  systems  intended  for  test  purposes  would  link  the  one  group  facility  (A) 
with  another  (B).  On  the  24  -  25  Jun  98  we  did  the  installation  of  the  IR  wireless 
components.  The  two  station  units  were  mounted  on  the  walls  outside  the  group  facility 
rooms.  Power  was  supplied  to  the  units  and  a  single  Ethernet  Cat  5  cable  was  run  from 
the  each  of  the  station  units  to  CISCO  1900  series  hubs  respectively  located  in  each 
room. 

On  the  10  - 1 1  Jul  98  welders  mounted  two  supporting  brackets  on  the  walls  in  close 
proximity  to  the  IR  wireless  components,  which  were  intended  to  support  the  RF  wireless 
components.  On  19  Jul  98  the  RF  the  test  team  installed  wireless  components. 

Both  of  the  wireless  systems  make  use  of  the  Ethernet  cabling  leading  to  each  of  the 
respective  spaces  and  therefore  were  tested  separately. 
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In  order  to  fulfill  evaluate  a  requirement,  INTRNET  access  was  established  in  one 
location  B.  A  passive  tap  was  established  by  temporarily  interrupting  the  fiber  optic  link 
and  inserting  two  fiber  optic  transceivers  (CentreCOM  MX26F)  that  are  connected  to  an 
Elite  351ZTP  10  Base-T  concentrator.  This  in  effect  provides  INTRNET  access  within 
the  location  B.  In  order  to  provide  location  A  with  the  same  capability  (once  the  wireless 
systems  are  established),  an  Ethernet  cable  was  run  from  the  Elite  concentrator  to  the 
CISCO  hub.  The  connectivity  was  confirmed  by  using  a  laptop  to  issue  a  "ping" 
command  to  the  INTRNET  servers. 

Within  location  B  the  100  Base-T  Group  Systems  LAN  was  connected  (through  a  single 
Cat  5  crossover  cable)  to  the  10  Base-T  CISCO  hub  of  the  wireless  system.  The  features 
of  the  CISCO  hub  make  it  possible  to  bridge  between  a  Fast  Ethernet  system  (100  Base- 
T)  and  the  10  Base-T  system. 

Testing  Details 

Ideally  to  provide  a  comprehensive  assessment  of  the  IR  and  RF  wireless  technologies, 
testing  should  comprise  of  stressing  CSMA/CA,  bandwidth  (Bw)  capacity  and  bit  error 
rate  and  comparing  FHSS,  DSSS,  and  IR.  Unfortunately  due  to  the  lack  of  test 
equipment  available  the  sole  criterion  for  assessment  is  the  Bw  capacity  of  each  of  the 
systems.  This  in  itself  is  qualitatively  assessed  as  testing  is  carried  out  through  the  use  of 
software  programs  and  tools.  The  minimum  Bw  sought  is  the  amount  required  to 
effectively  transfer  data,  stream  both  audio  and  video. 

To  facilitate  streaming  audio  and  video  a  PC  camera,  ComperEyes/PCI  and  sound  cards 
were  installed  in  Station  5  of  the  Group  Systems  LAN  within  the  on  location.  The 
software  provided  to  aid  in  the  audio/video  testing  is  CU-SeeMe  3.1  from  White  Pines 
Software. 

IR  Wireless  System 

Once  location  A  had  access  to  the  INTRNET  and  the  two  hubs  within  the  other  location 
were  connected,  a  notebook  running  Windows  NT  4.0  was  used  to  issue  a  "ping" 
command  to  the  two  INTRNET  servers  on  board.  After  this  effort  was  found  to  be 
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successful,  an  attempt  was  made  from  Station  5  in  location  B  to  connect  with  the 
Netscape  homepage  on  the  Internet  that  also  proved  successful.  To  test  the  data  transfer 
capability  the  latest  beta  version  of  Netscape  Communicator  was  downloaded.  The 
browser  was  successfully  downloaded  and  subsequently  installed  in  all  stations  within  the 
LAN.  At  that  point,  all  stations  were  able  to  access  the  Internet  concurrently. 

The  rate  at  which  the  data  transfer  took  place  was  indicative  of  normal  transfer  rates 
experienced  with  a  28.8/33.6Kbps  modem  connected  through  a  normal  telephone 
connection. 

As  previously  indicated,  a  PC  camera  with  associated  software  and  hardware  was 
installed  in  Station  5  of  location  B.  It  was  then  determined  amongst  the  test  team  that 
making  use  of  a  software  package  capable  of  performing  video  conferencing  would 
provide  an  indication  of  the  capability  for  the  IR  system  to  handle  streamed  audio  and 
streamed  video.  Since  Microsoft  offers  free  use  of  NetMeeting,  this  would  be  the  vehicle 

t 

to  test  the  wireless  systems  vice  using  CU-SeeMe  3.1. 

NetMeeting  2.1  was  subsequently  downloaded  from  the  Microsoft  Web  site  and  installed 
on  Station  5  of  location  B.  NetMeeting  was  also  downloaded  and  installed  on  the 
unclassified  Toshiba  computer  in  location  A.  The  first  videoconference  was  established 
using  Internet  Protocol.  Good  quality  video  viewing  was  present,  but  problems  were 
experienced  using  the  audio  portion.  No  audio  was  received  at  Station  5;  whereas,  audio 
was  received  at  location  A.  The  audio  received  was  clear  but  feedback  was  evident.  The 
audio/video  setup  feature  within  NetMeeting  was  performed  on  the  Station  5  and  proved 
correct.  The  same  test  was  performed  at  location  A’s  end  and  it  was  determined  that  the 
audio  record  function  was  not  functioning.  Therefore  speech  is  not  being  relayed  from 
the  monitor's  microphone  onwards  for  subsequent  processing.  This  has  been  noted  for 
further  investigation/rectification. 

A  second  computer  (Toshiba  440CDT  notebook)  was  subsequently  integrated  into  the 
test  process.  An  Intel  USB  Camera  II  (for  Intel  ProShare  -  Technology)  was  installed  on 
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the  notebook  and  NetMeeting  was  downloaded  and  installed.  NetMeeting  was  set  up 
correctly  and  a  videoconference  with  Station  5  was  initiated. 

During  the  conduct  of  this  videoconference  the  audio  and  video  elements  were  of  very 
good  quality.  Audio  feedback  was  present  and  it  was  noticed  that  regenerative  feedback 
could  easily  occur  and  disrupt  the  audio  portion  of  the  connection.  The  software  settings 
for  the  microphone  and  speaker  volumes  must  be  set  with  care  in  order  to  prevent  this 
feedback.  To  further  test  the  system,  the  remaining  features  of  NetMeeting  (application¬ 
sharing,  whiteboard  and  chat)  were  used.  The  chat  and  white  boarding  were  conducted 
and  then  an  MS  Word  document  was  shared  between  the  test  locations  in  a  collaborative 
effort.  All  these  functions  were  conducted  while  maintaining  the  audio  and  video  link. 

The  successful  result  of  this  test  was  the  major  milestone  the  test  team  wanted  to  achieve 
during  the  wireless  evaluation.  Further  testing  with  NetMeeting  is  possible  where  a 
larger  number  of  people  participating  in  a  meeting  will  challenge  the  available  network 
bandwidth.  This  was  not  attainable  during  this  evaluation  due  to  the  lack  of  PC  cameras 
available. 

One  additional  milestone  was  achieved  in  that  the  test  team  was  able  to  successfully 
incorporate  a  distributed  group  member  into  a  GroupSystems  session.  The  client  was 
located  in  the  location  A  and  the  member  was  able  to  participate  in  a  group  session  using 
NetMeeting  audio/video  capability  and  enter  comments  into  the  remote  GroupSystems 
session. 

RF  Wireless  System 

A  simple  bench  test  was  attempted  to  determine  connectivity  with  the  RF  system.  The 
XJ-4000F-C  transceiver  was  connected  to  an  antenna  via  the  SMA  female  connector  and 
to  a  hub  via  the  attachment  unit  interface  (AUI)  port.  A  notebook  was  then  connected  to 
the  hub  and  the  system  was  powered  up.  Another  identically  configured  sub-system  was 
erected.  The  method  of  testing  connectivity  was  to  issue  a  “ping”  command  from 
notebook  to  another,  which  subsequently  proved  correct.  The  next  step  in  testing  was  to 
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separate  the  two  sub-systems:  one  situated  in  the  location  with  the  other  situated  outside 
of  location  door.  The  associated  connectivity  test  proved  correct  (issuing  a  "ping" 
command)  with  the  following  observations: 

a.  Special  care  in  aligning  the  small  antenna  must  take  place  in  order  to  gain 
consistent  connectivity;  and 

b.  The  smaller  antenna  proved  more  reliable  than  the  larger  Hyperlink 
antenna  sub-system. 

The  RF  components  were  dismantled  and  re-assembled  on  the  platforms  mounted  on  the 
walls.  When  the  wireless  system  was  then  powered  up,  a  lack  of  connectivity  was 
discovered.  As  mentioned  above  concerning  antenna  alignment,  a  great  deal  of  effort  and 
care  was  expended  attempting  to  align  the  antennas  in  various  positions  to  no  avail.  It  is 
important  to  note  that  the  distance  between  the  antennas  was  less  than  10m  with  no 
obstructions. 

The  RF  system  was  dismantled  and  bench  tested  again  to  confirm  no  unserviceable 
components.  As  no  faults  were  discovered  the  two  subsystems  were  separated  again  to 
positions  within  the  one  location  and  outside  of  the  other.  Once  again  a  great  deal  of 
attention  was  given  to  aligning  the  antennas.  Continuous  connectivity  was  quite  difficult 
in  attaining,  but  at  one  point  a  5-minute  period  of  connectivity  was  established.  During 
this  time  access  to  the  Internet  was  gained  and  via  the  ABCNEWS.com  Web  site  the 
downloading  of  video  and  audio  news  clips  was  successfully  conducted. 

After  consulting  with  personnel  from  Clarion,  configurations  of  the  transceivers  were 
confirmed  correct  while  reasons  for  lack  of  continuous  connectivity  remain  unknown.  A 
final  attempt  to  test  the  RF  system  was  conducted  using  software  provided  by  Clarion. 
Approximately  approximately  10m  separated  the  two  sub-systems  in  the  spaces  adjacent 
to  the  JMC.  The  software  was  run  and  the  transceiver  and  hub  lamp  indications  were 
noted  as  follows: 

a.  Transmitting  sub-system: 

(1)  Hub  activity  lamp  consistently  indicated  data  traffic,  and 

(2)  XJ-4000F-C  transceiver  transmit  lamp  brightly  lit 
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b.  Receiving  sub-system: 

(1)  Hub  activity  lamp  consistently  indicated  no  data  traffic,  and 

(2)  XJ-4000F-C  transceiver  receive  lamp  intermittently  lit  with  low 
brilliance 

The  software  (Traffic.exe)  provided  by  Clarion  essentially  allows  a  computer  to  instigate 
a  constant  stream  of  data  for  the  purposes  of  testing  the  RF  system  or  align  the  associated 
antennas.  When  the  antennas  were  optimally  aligned  the  above  lamp  indication  was 
noted.  Since  all  units  were  assumed  to  function  correctly  one  can  speculate  that  the  steel 
walls  of  the  space  were  reflecting  the  signal  and  possibly  interfering  with  direct  line  of 
sight  reception.  The  evidence  for  this  is  provided  by  the  receiving  activity  of  the 
transceiver  while  the  hub  registered  no  data  activity,  thus  indicating  the  possible 
existence  of  errors  in  reception. 

It  was  decided  to  cease  further  RF  wireless  testing  and  advise  Clarion  Wireless  LAN 
Division  of  our  results. 

Noteworthy  Concerns 

During  the  "hotwork"  activity  in  spot  welding  the  brackets  in  the  vicinity  of  the  IR 
communications  link  was  interrupted  which  required  re-alignment  in  order  to  re-establish 
link.  This  happened  twice  during  the  mounting  of  the  two  brackets.  It  is  therefore 
advisable  not  to  run  the  IR  wireless  in  areas  of  excessive  heat. 

While  attempting  to  download  audio/video  clips  from  various  Internet  Web  sites, 
warnings  were  presented  relating  to  network  transport.  When  investigating  these 
warnings  the  end  result  is  that  TCP  network  transport  will  not  function  due  to  firewall 
restrictions.  Current  policy  in  place,  which  precludes  the  ability  to  use  collaborative 
audio/visual  Internet  communications  beyond  an  installation,  is  a  potential  concern  in  the 
future. 

Due  to  the  nature  of  transmission  used  in  the  RF  wireless,  2.4  GHz  at  25  mW,  the 
operation  of  the  RF  wireless  falls  into  the  EMCON  policy.  The  reasoning  for  this  is  that 
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regulations  preclude  the  use  of  electronic  systems  that  emit  RF  radiation  during  the 
uploading/downloading  of  ammunition.  Although  the  power  at  which  the  RF  wireless 
operates  is  extremely  low,  the  authorities  choose  to  error  on  the  side  of  safety.  Until  this 
can  be  resolved,  it  is  unadvisable  to  further  investigate  the  employment  of  RF  wireless 
systems  at  installations  employ  electrically  fired  ammunition. 


Accomplishments 

During  the  conduct  of  the  wireless  investigations,  the  following  accomplishments  have 
been  attained: 

•  Location  A  connectivity  to  the  INTRNET 

•  Location  B  connectivity  to  the  INTRNET 

•  Tested  two  wireless  LAN  systems:  IR  system  from  JVC  and  RF  from  Clarion 

•  Established  collaborative  NetMeeting  connectivity  between  location  A  and 
location  B  via  the  IR  wireless  system 

•  Established  a  distributed  client  for  Group  Systems  in  the  location  A. 

Recommendations 

The  recommendations  resulting  from  this  investigation  are  as  follows: 

•  Pursue  further  IR  wireless  investigation  possibly  with  COTS  products  available 
from  venders  such  as  JVC. 

•  If  RF  wireless  investigations  are  pursued  it  is  recommended  the  emission  control 
policy  is  ratified  to  allow  restriction-free  use  of  the  RF  wireless  systems. 

•  Resolve  firewall  restrictions  that  prevent  Internet  collaborative  video 
conferencing,  which  extend  the  capabilities  of  both  location  A  and  B. 

2.4  Artificial  Intelligence  Facilitation  and  Methodology 

Background 

Prior  work  by  researchers  at  the  University  of  Arizona  (Orwig,  et  al.,  1994)  found 
significant  problems  in  facilitated  meetings.  In  particular,  although  participant 
satisfaction  was  found  to  rise  during  divergent  activities  such  as  brainstorming, 
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satisfaction  was  found  to  decline  precipitously  during  subsequent  convergent  activities 
such  as  organizing  and  voting  on  the  material  generated  during  the  divergent  activity. 

These  researchers  found  that  a  key  reason  for  declining  satisfaction  was  the  amount  of 
time  spent  organizing  the  material  from  the  divergent  activity.  They  successfully 
decreased  the  time  spent  organizing  material  by  applying  a  neural  network  technique 
pioneered  by  Teuvo  Kohonen,  the  self-organizing  feature  map.  This  map  attempts  to 
show  the  relationship  between  comments  generated  in  a  brainstorming  session  on  a 
display  resembling  a  chloropleth  map.  This  work  is  useful  in  providing  tools  for 
knowledge  management  to  help  maintain  organizational  memory.  Output  from 
brainstorming  sessions  and  other  electronic  meetings  becomes  more  easily  accessible 
because  the  tool  sorts  it  or  categorizes  the  information  into  a  map  of  topics  relating  to  a 
particular  question.  Users  then  can  more  readily  find  that  information  in  which  they  are 
most  interested. 

While  the  earlier  work  succeeded  in  many  ways,  certain  aspects  of  the  self-organizing 
feature  map  left  room  for  further  research.  First,  the  technique  organizes  comments  at  the 
intersections  of  lines  arranged  in  a  two-dimensional  grid,  permitting  only  an  extremely 
coarse  and  often  inaccurate  portrayal  of  the  similarity  relationships  between  comments. 
Second,  users  are  often  baffled  by  the  map’s  interface,  and  are  rarely  able  to  use  it 
without  instruction.  Third,  although  the  map  can  be  generated  quickly  enough  to  provide 
a  time  saving  over  purely  manual  organization,  practical  use  would  benefit  from  a 
considerably  faster  process.  Finally,  the  earlier  work  did  not  address  the  problem  of 
preprocessing  the  comments,  using  only  one  method,  automatic  indexing,  to  prepare 
comments  for  mapping.  Because  they  only  used  one  input  method,  the  researchers  had 
no  idea  whether  automatic  indexing  performed  better  than  other  available  methods. 

The  present  work  provides  tools  to  aid  facilitation  that  aim  to  overcome  some  of  the 
limitations  of  the  earlier  tools.  We  have  also  tested  the  newer  tools  to  validate  the 
technique  and  to  explore  comments  generated  during  the  course  of  the  DOME  project. 
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The  Tools 


Several  tools  were  developed  in  the  course  of  the  research,  while  several  tools  developed 
separately  by  the  University  of  Arizona  AI  Group  were  used  in  this  research.  The 
following  tools  were  used  in  the  order  listed  below. 

preprocessors 

Two  different  preprocessors  were  used  to  transform  comments  (output  from 
GroupSystems)  into  lists  of  terms  suitable  for  analysis.  The  first  was  the  automatic 
indexer  previously  developed  by  Dorbin  Ng  and  other  researchers  in  the  AI  Group.  This 
tool  converts  comments  into  single-word  and  multi-word  terms  after  filtering  out  stop- 
words  (common  words  that  don’t  differentiate  comments).  The  automatic  indexer  does 
not  distinguish  between  parts  of  speech  represented  by  terms,  which  are  developed  with  a 
moving  window  technique  (a  “moving  window”  is  passed  across  text  to  create 
keywords). 

The  second  preprocessor,  the  Arizona  Noun  Phraser,  is  a  more  recent  development  in  the 
AI  Group.  This  system  makes  a  strong  guess  at  the  part  of  speech  represented  by  a 
single-  or  multi-word  phrase  and  captures  only  noun  phrases.  We  compared  this  to  the 
earlier  approach,  believing  that  this  approach  would  result  in  better  representation  of 
comments,  but  were  surprised  by  the  results. 

DISSIM 

This  simple  tool  calculates  the  “dissimilarity”  between  comments  based  on  classic  ideas 
of  document  similarity  from  information  retrieval.  This  dissimilarity  is  based  on  the 
Jaccard  score  described  in  information  retrieval  literature  (Tversky,  1978).  The  Jaccard 
score  calculates  similarity,  S,  between  two  objects  x  andy  as 

L  xnz 

|x|  +  |y|-|xny|  ‘ 

DISSIM  calculates  the  similarity  between  comments  by  the  above  formula,  using  term 
lists  generated  by  the  previous  step.  Like  most  similarity  measures,  the  Jaccard  score 
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provides  a  numerator  to  represent  the  number  of  terms  in  common  between  the  two 
comments  and  a  denominator  to  scale  the  results  by  the  total  number  of  terms  in  the  two 
comments.  Hence,  if  two  comments  share  only  the  term  “lead  time”  and  contain  no  other 
terms,  they  are  judged  to  be  more  similar  than  two  comments  that  share  the  term  “lead 
time”  but  also  each  have  3  terms  not  in  common. 

The  DISSIM  tool  stores  the  values 
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scaled  to  a  5  digit  integer  for  each  row  m  and  each  column  n  of  the  similarity  matrix. 

This  produces  a  dissimilarity  matrix,  analogous  to  a  city  distance  table,  with  the 
important  exception  that  some  of  the  entries  are  contradictory.  For  instance,  imagine  a 
city  distance  table  where  New  York  lies  between  Boston  and  Washington,  but  Boston  lies 
between  New  York  and  Washington.  Such  a  city  distance  table  could  not  be  represented 
on  a  map  without  some  way  to  resolve  these  contradictions.  This  helps  motivate  the  next 
step,  which  resolves  the  contradictions  in  a  manner  that  is  in  some  sense  optimal 

MDSca ler 

This  tool  uses  isotonic  regression  and  conjugate  gradient  descent  algorithms  to  perform 
non-metric  multidimensional  scaling  as  described  by  Kruskal  (Kruskal,  1964).  The 
output  is  in  the  form  of  coordinates  for  a  map  of  comments  in  one,  two,  or  three 
dimensions.  The  3D  output  takes  the  form  of  VRML  tags,  while  the  2D  output  is  suitable 
for  either  of  the  two  Java  interfaces  described  below.  The  ID  form  is  not  for  display  but 
is  used  for  categorization. 

This  tool  begins  by  assigning  optimal  distances  between  comments  i  and  j  such  that 


or,  in  words,  the  optimal  distance  between  two  objects  is  less  than  or  equal  to  the  optimal 
distance  between  two  other  objects  if  and  only  if  the  optimal  dissimilarity  between  those 
two  objects  is  strictly  less  than  the  optimal  dissimilarity  between  the  other  two  objects. 
Having  found  these  optimal  distances,  the  tool  finds  coordinates  in  1, 2,  or  3  dimensions 
that  minimize 
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the  STRESS  function  originally  defined  by  Kruskal  (Kruskal,  1964).  Although  this 
function  has  been  the  subject  of  a  never-ending  stream  of  scholarly  articles  in  recent 
years,  no  one  has  satisfactorily  demonstrated  a  function  that  strictly  dominates  it.  We 
have  chosen  to  implement  the  original  function,  albeit  in  a  modular  way  that  can  be  easily 
replaced  with  a  superior  replacement,  should  one  emerge. 

oned 

This  new  tool  (pronounced  “wun-dee”)  is  used  to  categorize  comments  based  on  the 
output  of  ID  MDScaler.  Currently,  it  finds  the  largest  gaps  in  distance  in  the  ID 
configuration,  and  records  the  categorizations  that  result  from  dividing  the  comments  at 
these  gaps.  The  output  is  a  list  of  n  - 1  categorizations  given  input  of  n  coordinates. 

interfaces 

We  implemented  two  interfaces  in  Java.  The  first  interface  provides  three  windows  and 
several  controls.  The  main  window  displays  the  map,  showing  comments  as  colored 
dots.  The  user  may  select  comments  by  clicking  on  dots  or  dragging  a  rectangle  around  a 
group  of  dots.  A  second  window  displays  the  text  of  currently  selected  comments, 
shaded  with  colors  that  match  the  dot  colors.  A  third  window  displays  the  colors  in  use 
and  permits  the  user  to  assign  a  name  to  the  categories  represented  by  these  colors. 

The  second  interface  differs  in  both  design  and  implementation.  This  interface  uses  more 
recent  Java  tools  to  ease  further  development  and  is  generally  more  robust.  Although  it 
has  been  designed  to  permit  more  flexible  development,  only  one  major  addition  has  been 
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implemented  to  date.  This  addition  permits  animation  of  the  categorizations  found  by 
Oned.  In  future,  it  will  support  automatic  naming  of  categorizations. 

Results 


Testing 

Initial  testing  of  the  system  is  described  in  detail  in  (McQuaid,  Ong,  Chen,  and 
Nunamaker,  1999).  This  testing  involved  an  experiment  with  60  users,  30  using  the 
actual  system  and  30  using  a  “placebo”  system  to  determine  whether  the  system  could 
provide  statistically  significant  benefits  to  facilitators. 

More  recent  testing  has  involved  processing  of  comments  generated  in  the  DOME 
project.  For  these  tests  we  have  generated  maps  based  on  both  preprocessors  and 
compared  them  with  the  aid  of  a  domain  expert.  Our  evaluation  of  this  testing  is  reported 
below. 

Evaluation 

Our  system  does  a  simple  form  of  machine  learning,  described  in  the  machine  learning 
literature  as  statistical  learning,  specifically  multidimensional  scaling.  The  advantage 
ascribed  to  this  technique  in  AI  literature  is  that  it  remains  immune  to  the  prejudices  of 
the  researcher  in  finding  patterns.  It  finds  patterns  in  the  most  rudimentary  way: 
translating  the  dissimilarities  described  above  into  distances  on  (for  instance)  a  2D  map. 
The  disadvantage  of  this  approach  is  that  the  patterns  found  may  have  no  semantic 
content.  For  instance,  the  tool  may  find  that  two  comments  containing  the  term  “rock” 
are  similar,  even  though  one  comment  addresses  music  and  the  other  addresses  geology. 
The  system  does  not  do  word  sense  disambiguation.  This  simplicity  can  have 
serendipitous  consequences.  For  instance,  the  system  clustered  “group  memory”  and 
“organizational  memory”  in  close  proximity  due  to  the  common  term  “memory.”  This 
was  a  desirable  but  accidental  result,  since  the  system  had  no  thesaurus  to  refer  to  find  a 
link  between  “group”  and  “memory.” 

We  implemented  two  interfaces  in  Java.  The  first  was  designed  to  validate  the  system  by 
allowing  users  to  interactively  categorize  comments  on  a  pre-built  map.  This  interface 
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can  also  be  used  by  a  facilitator  to  more  quickly  categorize  comments  than  is  possible 
using  a  purely  manual  approach. 


In  Figure  1  we  see  the  first  Java  interface  using  comments  preprocessed  by  automatic 
indexing.  Two  problem  comments  are  selected  in  this  figure.  Note  that  the  comments 
labeled,  “Problems”  are  more  dispersed  than  the  comments  labeled,  “Solutions.”  The 
language  of  the  problem  comments  is  actually  more  varied  than  the  language  of  the 
solution  comments. 


Figure  1.  Java  Interface  (1)  with  Comments  Preprocessed  by  Automatic  Indexing 


In  Figure  2  we  see  the  first  Java  interface  using  comments  preprocessed  by  norm 
phrasing.  One  solution  comment  is  selected  in  this  figure.  The  configuration  of  the 
Problem  comments  and  the  Solution  comments  is  notable  in  that  they  form  similar, 
parallel  ellipses.  A  domain  expert  who  reviewed  the  output  indicated  that  he  observed 
substantial  similarities  between  Problem  and  Solution  comments  in  corresponding 
locations. 


Figure  2.  Java  Interface  with  Comments  Preprocessed  by  Noun  Phrasing 

In  Figure  3  we  see  the  second  Java  interface  using  comments  preprocessed  by  automatic 
indexing.  Four  comments  in  the  upper  right  comer  (surrounding  the  cursor)  are  selected. 
These  comments  concern  the  term  “goals”  which  is  peripheral  to  the  main  discussion  of 
change  management.  An  important  feature  of  this  system  is  that  it  separates  comments 
that  are  peripheral  (in  the  sense  of  sharing  no  keywords)  to  the  main  text  (as  represented 
by  the  large  semicircular  border).  The  ability  to  distinguish  this  kind  of  peripheral 
material  was  important  to  users  of  earlier  tools,  so  in  moving  to  different  techniques,  it 
would  be  easy  and  unfortunate  to  lose  this  feature. 

Our  testing  sought  to  verify  our  intuition  that  one  type  of  preprocessing  would  by 
preferred  by  users.  Our  intuition  was  contradicted  by  the  reaction  of  a  domain  expert, 
who  preferred  to  see  multiple  views,  i.e.,  the  two  views  shown  in  Figures  1  and  2.  The 
expert  pointed  out  that  discussion  participants  sometimes  expressed  agreement  with 
comments  by  repeating  predicates  (or  predicate  fragments)  in  other  comments.  By 
restricting  the  processing  to  noun  phrases,  the  domain  expert  felt  that  we  showed  some 
important  associations,  but  missed  some  associations,  specifically  between  predicates. 


1.  Having  to  many  goals  and  expectations  is  worse  than  not  having  any.{£57;- 

2.  Idea!  Is  to  have  some  qoals  {#128> 

3.  Sometimes  when  you  setyour  goa  I  too  low,  you’ll  relax  too  much  afteryou  achieve  it.  {£580} 

4.  High  goals  are  good,  but  don't  torgetto  se:  smaller  landmarks  slang  the  way.  A1  leas:  that  way 
you  feel  like  you  are  getting  somewhere.  {£21 5} 


Figure  3.  Java  Interface  (2)  with  Comments  Preprocessed  by  Automatic  Indexing 


2.5  Development  of  Distributed  Process  Modeler 
Awareness  of  the  need  for  business  analysis  has  grown  faster  than  the  evolution  of  tools 
to  support  the  collaborative  development  of  business  models.  Appropriate  models  may 
support  conceptualization,  communication,  analysis,  and  design  of  improved  business 
processes  and  information  systems.  In  addition,  involvement  of  key  personnel  during 
model  development  and  analysis  is  important  for  model  accuracy  as  well  as  for  buy-in. 
Traditionally,  however,  models  have  been  developed  by  individuals  and  small  groups 
because  of  the  complexity  and  difficulties  involved  in  the  modeling  process. 
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Researchers  at  the  University  of  Arizona  have  worked  for  the  past  several  years  creating 
specialized  electronic  meeting  systems  (EMS)  tools  and  methods  to  support  the 
development  of  various  types  of  business  models.  These  tools  include  Activity  Modeler, 
for  developing  IDEFO  activity  models,  and  Group  Data  Modeler,  for  developing 
enterprise  data  models.  These  tools  and  methods  were  designed  to  effectively  involve 
users  in  the  development  of  business  models  and  are  an  important  part  of  the 
Collaborative  Software  Engineering  Methodology  (CSEM).  One  key  aspect  of  CSEM 
describes  the  use  of  scenarios  to  capture  business  process  information  and  to  develop 
process  models.  Although  there  are  single-user  process  modeling  tools  available,  there 
are  not  any  tools  specifically  designed  to  support  collaborative  process  modeling.  This 
section  discusses  the  creation  of  the  distributed  Process  Modeler  (PM)  tool,  which  was 
developed  to  support  this  aspect  of  CSEM. 

2.5.1  Background 

Previous  research  in  the  development  of  IDEFO  activity  models  showed  that  these  models 
were  very  well  suited  for  describing  “what”  an  organization  does,  but  lacked  some 
important  details  such  as  timing  and  sequence  of  activities,  and  decision  logic.  Further 
research  determined  that  business  process  models  could  be  used  to  capture  this  additional 
information. 

A  process  model  can  be  described  as  “an  abstract  description  of  an  actual  or  proposed 
process  that  represents  selected  process  elements  that  are  considered  important  to  the 
purpose  of  the  model  and  can  be  enacted  by  a  human  or  a  machine.”  Process  models  can 
be  developed  from  different  perspectives  such  as  functional,  informational,  behavioral,  or 
organizational  perspectives.  In  MIS,  some  of  the  earliest  process  models  (e.g.,  data  flow 
diagrams)  took  a  functional  perspective.  Business  process  reengineering  and  other 
process  improvement  initiatives  have  focused  on  the  behavioral  and  organizational 
perspectives  for  modeling  general  business  processes.  These  business  process  models 
include  information  such  as  process  sequence,  decision  criteria,  and  who  performs  the 
process. 
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In  the  process  modeling  world,  one  of  the  best  specified  languages  for  representing  work 
processes  in  the  physical  world  is  IDEF3.  The  IDEF3  Process  Description  Capture 
Method  was  developed  by  Knowledge  Based  Systems,  Inc.  (KBSI)  for  the  U.S.  Air  Force 
as  part  of  its  Integrated  Computer-Aided  Manufacturing  (ICAM)  Definition  (IDEF)  of 
methods  program.  The  basic  process  element  in  IDEF3  is  the  “Unit  of  Behavior  (UOB)” 
which  describes  “things  that  happen  in  the  world”  (e.g.,  function,  process,  scenario, 
activity,  action,  operation,  event,  decision,  or  procedure).  The  other  major  IDEF3 
constructs  are  links  used  to  specify  relationships  between  UOBs  (e.g.,  temporal 
precedence,  constraints,  object  flows,  or  relationships)  and  junctions  which  can  be  used 
to  ‘join’  two  or  more  links  together  or  to  ‘fork’  out  to  links  to  two  or  more  processes. 
Junctions  are  annotated  to  indicate  the  timing  of  forks  and  joins  as  synchronous  or 
asynchronous. 

As  can  be  seen  from  the  preceding  discussion,  the  IDEF3  process  description  method 
provides  a  comprehensive  business  process  modeling  capability.  However,  University  of 
Arizona  researchers’  experiences  with  IDEF3  indicate  that  some  portions,  such  as  the 
different  types  of  synchronous  and  asynchronous  junctions,  may  be  too  complex  for  users 
to  quickly  grasp.  Therefore,  while  the  capabilities  of  IDEF3  served  as  input  to  the  PM 
requirements  process,  several  other  alternatives  were  investigated  in  the  search  for  a 
simplified,  easy-to-use  graphical  process  modeling  technique.  Petri-nets  were  eliminator! 

from  consideration  since  they  are  even  more  complex  than  IDEF3.  In  contrast,  several 
Unified  Modeling  Language  diagrams  seemed  to  have  potential  as  a  user-comprehensible 
representation. 

The  Unified  Modeling  Language  (UML)  was  adopted  by  the  Object  Management  Group 
as  the  standard  object-oriented  modeling  language.  The  UML  standard  defines  several 
diagrams  for  behavior  modeling  that  could  possibly  be  used  to  graphically  portray 
business  processes.  UML’s  Sequence  Diagram  is  commonly  used  to  document  use  case 
scenarios.  It  is  a  type  of  interaction  diagram  that  shows  the  objects  participating  in  a 
scenario  and  a  time-sequenced  list  of  messages  the  objects  exchange  to  accomplish  the 
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scenario  goal  [2].  The  Sequence  Diagram’s  focus  on  objects  and  messages  increases  its 
complexity  beyond  what  is  desirable  for  a  simplified,  graphical  process  modeling 
.technique  targeted  to  non-analyst  users.  UML’s  State  Diagrams  are  also  too  complicated 
for  users  to  independently  create  without  significant  training  and  assistance  from  analysts 
or  modelers.  These  technical  diagrams  are  more  suitable  for  use  by  experienced  analysts 
and  developers  than  by  untrained  users. 

In  contrast,  UML’s  Activity  Diagram  is  a  greatly  simplified  version  of  the  UML  state 
diagram  that  can  easily  be  used  for  business  process  modeling.  It  is  designed  to  provide  a 
dynamic  view  of  a  system  or  process  that  shows  the  flow  from  activity  to  activity. 
Officially  it  is  defined  as  “a  special  case  of  a  state  diagram  in  which  all  or  most  of  the 
states  are  action  states  and  in  which  all  or  most  of  the  transitions  are  triggered  by 
completion  of  actions  in  the  source  states”.  The  basic  constructs  in  the  UML  Activity 
Diagram  are  defined  in  Table  1 .  These  definitions  seem  rather  technical,  however,  they 
are  relatively  simple  in  practice.  Activity  and  action  states  are  directly  comparable  to 
IDEF3’s  UOB  and  can  be  used  to  represent  a  business  process  and  the  steps  in  the 
process,  respectively. 


Activity  Diagram  Construct 

Description 

Action  State 

Represents  the  execution  of  an  atomic  action.  A  simple  state 
with  an  entry  action  whose  only  exit  transition  is  triggered 
by  the  implicit  event  of  completing  the  entry  action. 

Activity  State 

Represents  the  execution  of  a  non-atomic  sequence  of  steps 
that  has  some  duration.  A  hierarchical  action  where  an 
associated  sub-activity  model  is  executed. 

Pseudo  State 

Abstraction  of  different  types  of  nodes  in  a  state  machine 
graph  which  function  as  transient  points  in  transitions  from 
one  state  to  another,  such  as  branching  and  forking,  simple 
transitions,  or  object  flows. 

Table  1.  UML  Activity  Diagram  Constructs 
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The  user  does  not  even  have  to  be  concerned  with  the  difference  between  activity  and 
action  states  since  they  are  both  represented  with  the  same  graphical  symbol  (Figure  4). 


- j 

Activity/Action 
State  Name 

_ J 


Decision 


Fork  or  Join 


-►  Transition 
►  Object  Flow 


Activity  and  Action  States 


Pseudo-States 


Figure  4.  UML  Activity  Diagram  Graphical  Symbols 


The  graphical  symbols  for  pseudo-states  are  also  much  simpler  than  its  definition  would 
imply.  The  decision,  fork,  and  join  pseudo-states  are  simply  different  types  of  branches 
that  can  occur  in  process  flows  and  are  comparable  to  IDEF3  junctions.  Transitions  and 
object  flows  represent  two  types  of  links  between  activity  or  action  states. 

In  summary,  both  IDEF3  and  the  UML  Activity  Diagram  satisfy  PM’s  requirement  for 
graphical  business  process  modeling.  The  basic  elements  of  each  are  directly 
comparable.  However,  because  the  Activity  Diagram  has  a  simpler  representation  and 
can  be  linked  to  other  UML  diagrams,  it  was  selected  for  PM’s  initial  graphical  process 
modeling  representation. 

2.5.2  PM  Systems  Development 

The  goal  of  this  research  was  to  design  and  develop  a  new  system  that  provided  better 
support  for  collaborative  scenario  and  process  model  development  than  existing  tools. 
The  PM  prototype  evolved  from  the  lessons  learned  in  previous  research  [17, 18]  and  the 
integration  of  two  DOD  funded  research  prototypes:  (1)  Process  Modeler  and  (2) 

Scenario  Modeler.  Results  of  this  research  are  presented  in  the  following  sections  for 
each  of  the  five  stages  of  the  systems  development  research  methodology  [24]. 

2. 5.2.1  Construction  of  a  Conceptual  Framework 

The  CSEM  scenario  framework,  collaborative  scenario  elicitation  methodology,  and 

contextual  scenario  data  model  developed  and  revised  during  previous  research  served  as 
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the  overarching  conceptual  framework  for  this  research.  This  framework  served  as  the 
starting  point  for  investigating  the  required  functionality  for  the  PM  prototype.  Next,  the 
business  process  modeling  literature  was  studied  to  identify  alternative  approaches  for 
satisfying  those  requirements.  Results  of  these  first  two  steps  were  analyzed  to  develop 
an  integrated  scenario  and  process  modeling  framework  for  the  PM  prototype. 

2. 5. 2. 1.1  Core  PM  Prototype  Functionality 

The  lessons  learned  from  earlier  research  [17, 18]  were  combined  with  previous 
experiences  in  developing  general-purpose  and  modeling  GSS  to  identify  five  core 
requirements  for  PM: 

1 .  PM  must  include  all  GroupSystems  Group  Outliner  functionality  for  hierarchically 
decomposition  and  commenting  on  outline  items.  Users  consistently  rated  Group 
Outliner  very  easy-of-use,  therefore,  Group  Outliner  served  as  the  baseline  for  these 
capabilities. 

2.  PM  must  implement  the  essential  features  of  a  modeling  GSS  including  a  user- 
comprehensible  interface  that  focuses  on  information  the  user  can  provide.  Lessons 
learned  from  development  of  Activity  Modeler  and  Group  Data  Modeler  were  used  to 
guide  implementation  of  this  capability. 

3.  PM  must  be  application-specific  and  include  prompts  for  scenario  and  action  data 
included  in  the  contextual  scenario  data  model. 

4.  PM  must  provide  flexible  support  for  an  iterative  methodology  for  collaborative 
scenario  and  process  model  development. 

5.  PM  must  include  an  integrated  graphical  process  modeling  capability.  Business 
process  modeling  approaches  were  studied  to  identify  alternatives  for  providing  this 
capability. 

2. 5. 2. 1.2  integrated  Scenario  and  Process  Modeling  Framework 

The  initial  conceptual  framework  and  data  model  developed  during  earlier  research  were 
specifically  designed  to  support  scenario  elicitation.  Scenario  and  process  modeling  have 
very  different  constructs  and  terminology.  These  differences  had  to  be  reconciled  before 
an  integrated  scenario  and  process  modeling  capability  could  be  included  in  PM.  One  of 
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the  first  major  challenges  was  to  define  what  the  basic  components  that  are  successively 
decomposed  to  create  a  PM  process  model  are  and  what  they  should  be  called. 

The  CSEM  specifies  that  business  activities  and  functions  should  be  decomposed  into 
sub-activities/functions.  For  each  of  the  sub-activities/functions  with  system 
implications,  users  identify  business  scenarios,  which  provide  concrete  examples  of  how 
users  currently  accomplish  those  functions.  Business  scenarios  are  then  decomposed  into 
the  specific  steps  or  actions  that  users  perform  during  those  scenarios.  Using  CSEM  as  a 
guideline,  the  basic  PM  components  could  be  called  activities,  functions,  sub-activities, 
scenarios,  steps  or  actions  -  depending  on  the  level  of  the  decomposition. 

From  a  graphical  process  modeling  perspective,  processes  are  decomposed  into  sub¬ 
processes,  which  are  further  decomposed  into  tasks  or  actions.  The  UML  Activity 
Diagram  decomposes  activity  states  into  action  states.  Again,  the  name  of  the  component 
depends  on  the  level  of  decomposition.  The  IDEF3  Process  Description  Capture  Method 
eliminates  this  dependency  by  calling  all  the  basic  components  at  all  levels  “Units  of 
Behavior”  which  represent  a  function,  process,  scenario,  activity,  operation,  decision, 
action,  event,  or  procedure. 

While  the  IDEF3  concept  provided  the  simplicity  desired  for  the  PM  prototype,  it  was  not 
clear  whether  all  these  different  components  could  be  consolidated  into  one  generic 
element.  A  comparison  of  data  requirements  for  all  levels  for  both  scenarios  and 
processes  showed  that  there  was  enough  overlap  to  support  consolidation  into  a  single 
basic  component  with  standardized  data  elements.  The  other  advantages  of  consolidating 
into  a  single  component  are: 

•  The  abstraction  problem  (e.g.,  where  one  person’s  scenario  is  another’s  step,  or 
where  a  scenario  step  in  the  requirements  phase  becomes  a  use  case  during 
design)  does  not  have  to  be  dealt  with  -  all  components  will  be  the  same. 

•  The  user  does  not  have  to  understand  the  differences  between  the  separate 
components. 
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These  advantages,  when  combined  with  the  results  of  the  data  analysis,  resulted  in  the 
decision  to  combine  all  PM  components  at  all  levels  of  decomposition  into  a  single 
generic  component.  The  next  question  was  what  to  call  this  generic  component.  The 
IDEF3  term,  “unit  of  behavior,”  seemed  too  awkward.  After  extensive  discussion,  the 
term  “process”  was  selected  as  the  generic  term  to  represent  the  basic  components  of  the 
PM  model,  regardless  of  decomposition  level.  Therefore,  the  term  “process”  is  used 
whenever  the  component  being  referred  to  could  be  an  activity,  function,  sub¬ 
activity/function,  process,  sub-process,  scenario,  task,  action,  or  step. 

2. 5. 2. 1.3  PM  System  Building  Process 

The  PM  prototype  was  developed  using  a  collaborative,  incremental,  rapid  prototyping 
approach  to  systems  building.  Development  of  PM  was  a  team  effort,  with  each  team 
member  having  clearly  defined  roles  and  responsibilities.  The  project  leaders  served  as 
primary  researchers  and  requirements  engineers.  Other  team  members  served  as  system 
architect,  interface  designer,  and  programmers.  Critical  PM  requirements,  priority, 
design,  and  development  decisions  were  jointly  discussed  during  weekly  project  team 
meetings.  All  team  members  participated  in  the  discussion,  although  the  individual 
responsible  for  a  particular  area  had  final  decision  authority.  Increments  were  time- 
constrained  to  coincide  with  research  contract  deliverables.  Understanding  the  strengths 
and  weaknesses  of  the  prototyping  process  used  was  critical  to  successful  on-time 
delivery  of  the  first  version  of  PM  to  the  research  sponsors. 

2.5.3  Development  of  a  PM  System  Architecture 

The  PM  prototype  is  based  on  a  two-tier  client-server  architecture  to  support  distributed 
collaborative  computing.  This  architecture  allows  users  to  access  PM  through  Java- 
enabled  Web  browsers  regardless  of  their  location,  time  or  type  of  computer,  connecting 
to  a  server  capable  of  supporting  multiple  simultaneous  users.  PM  consists  of  three  main 
components:  the  server  component,  client  component  and  a  supporting  administration 
module. 

Server.  The  server  component  of  PM  is  developed  in  Delphi  and  resides  on  a  Windows 
NT  server.  It  processes  the  requests  from  clients,  stores  or  retrieves  the  data  from  the 
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back-end  Paradox  database  based  on  those  requests,  and  broadcasts  update  messages  to 
each  active  client.  There  are  two  types  of  tables  in  the  Paradox  databases  for  the  usage  of 
PM:  administration  tables  and  process-related  tables.  Six  administration  tables  keep 
information  about  sessions,  users,  privileges  and  login  passwords,  etc.  The  other  six 
tables  store  all  the  data  related  to  processes  created  in  the  sessions.  In  order  to  keep 
consistency  and  integrity  of  the  database  in  a  multi-user  environment,  the  server 
implements  required  concurrency  controls. 

Client.  The  PM  client  component  is  initialized  by  a  Java  applet  that  is  also  stored  on  the 
NT  server.  The  Java  applet  is  downloaded  through  the  Internet  to  the  client  computer 
whenever  an  authorized  user  logs  in.  A  copy  of  the  process  model  data  is  downloaded  to 
the  client  machine  when  the  user  selects  a  specific  process  modeling  session.  The  client 
component  has  a  graphical  user  interface  that  allows  users  to  perform  a  wide  variety  of 
tasks,  such  as  viewing,  adding,  editing  or  deleting  information  about  processes  in  the 
model.  Whenever  a  user  inputs  a  change,  the  process  model  data  on  the  client  machine  is 
updated  only  after  the  corresponding  data  physically  stored  on  the  server  has  been 
changed.  This  design  makes  the  system  more  efficient. 

Although  the  client  component  can  be  used  by  any  authorized  user,  facilitators  have 
additional  administrative  options,  including: 

•  Setting  or  modifying  the  session  configuration  by  specifying  what  panels  and 
prompts  to  display  through  the  facilitator  panel. 

•  Granting  or  modifying  user  privileges  by  defining  whether  users  have  the  rights  to 
view,  add,  modify,  or  delete  various  components  of  the  model 

•  Viewing  deleted  processes  and  recovering  them  if  necessary. 

Administration  Module.  The  administration  module  is  a  generic  module  supporting 
several  different  projects.  For  PM,  it  is  primarily  an  administration  utility  used  by  system 
administrators  and  facilitators.  Administrators  are  specially  designated  users  who  have 
all  privileges  including  those  required  to  create  PM  sessions,  maintain  user 
lists/passwords,  and  designate  users  as  session  facilitators.  Facilitators  have  access  to 
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their  own  sessions  and  can  use  the  administration  module  to:  create  PM  sessions, 
add/remove  users  to/from  a  session,  add  additional  facilitators  to  a  session,  and  perform 
general  session  file  management  and  clean-up. 

2.5.4  Analysis  and  Design  of  PM 

PM  analysis  and  design  was  a  team  effort  consisting  of  the  logical  database  and  user 
interface  design,  discussed  next.  PM  object  classes  are  summarized  later  in  this  section. 

2. 5.4.1  Logical  Database  Design 

The  logical  data  model  was  developed  by  adapting  the  proposed  contextual  scenario  data 
model  based  on  the  integrated  scenario  and  process  modeling  concepts  described  in 
section  4.1.2  and  adding  the  new  data  items  that  were  identified  during  development  of 
the  integrated  concept.  The  data  model  was  then  revised  further  to  take  advantage  of  the 
flexibility  provided  by  the  proposed  user  interface  design.  The  primary  entity  in  the 
model  is  the  process.  All  other  entities  are  either  directly  or  indirectly  related  to  process. 

2. 5.4.2  user  Interface  Design 

The  functional  requirements  provided  by  the  project  leaders  were  the  primary  input  for 
the  user  interface  design  process.  Different  non-functional  interface  alternatives,  each 
with  different  tradeoffs  dealing  with  ease  of  use  and  data  display,  were  mocked  up  using 
Microsoft  Visual  Basic.  By  presenting  and  discussing  strengths  and  weaknesses  of 
different  approaches  during  the  weekly  team  meetings,  the  best  components  of  each 
design  alternative  were  combined  to  create  the  final  screens.  Throughout  the  design 
process,  all  of  the  interface  design  considerations,  alternative  screen  mockups,  intended 
functionality,  and  system  behaviors  were  stored  in  a  web-based  planning  and  design 
repository  which  served  as  the  primary  focus  point  for  the  weekly  team  meetings  and 
allowed  each  of  the  team  members  to  revisit  the  screen  mockups  outside  of  the  regular 
meeting  times. 

The  final  interface  design  contained  three  primary  components:  a  hierarchical  tree 
structure  for  process  decomposition  (see  left  side  of  Figures  5  and  6),  a  tabbed  panel  text 
entry  area  to  record  details  about  each  process  in  the  tree  (see  right  side  of  Figure  5),  and 
a  graphical  area  used  for  process  depiction  (see  right  side  of  Figure  6).  The  hierarchical 
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tree  is  a  relatively  simple  tool,  which  supports  the  decomposition  of  processes  into  sub¬ 
processes  and  tasks. 
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Figure  5.  Process  hierarchy  and  Information  Panels 


The  text  entry  area  was  designed  to  capture  different  types  of  detailed  information  for 
each  process  in  the  tree  structure.  The  two  categories  of  data  that  can  be  captured  for 
each  process:  (1)  fixed-structure  data  (e.g..  Overview,  Metrics,  Actors)  and  (2)  generic, 
unstructured  textual  data  (e.g.,  Description,  Prerequisites,  Results),  each  with  its  own 
layout  and  appearance  in  the  tabbed  panel  display.  The  tabbed-panel  approach  provides  a 
method  for  displaying  and  accessing  a  great  deal  of  information  while  simultaneously 
conserving  screen  space.  The  fixed-structure  panel  format  cannot  be  changed,  and 
contains  fields,  which  are  geared  to  recording  specific  data  about  each  process  (e.g.,  cost, 
frequency,  viewpoint,  and  equipment  requirements).  The  generic  panels  provide  the 
flexibility  to  customize  PM  to  suit  specific  process  modeling  needs  in  a  wide  variety  of 
organizations.  Each  panel  contains  a  single  large  text  box  that  allows  the  users  to 
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describe  a  certain  aspect  of  the  current  process  (e.g.,  Prerequisites,  Results).  Each 
individual  item  input  by  a  user  creates  a  new  entry  in  the  respective  panel. 
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Figure  6.  Graphical  View  of  a  Process 


A  session  facilitator  has  the  ability  to  focus  the  attention  of  the  users  to  specific  aspects  of 
the  process  being  modeled  by  making  specific  tabbed  panels  visible  or  not.  For  example, 
if  all  panels  but  the  Description  panel  are  hidden  from  view,  the  users  can  focus  their 
attention  on  describing  each  process  in  the  tree.  Once  group  consensus  has  been 
achieved  on  the  process  description,  other  aspects  of  the  process  may  then  be  modeled  by 
making  the  appropriate  panels  visible.  Additionally,  if  there  is  some  dimension  of  the 
process  for  which  a  generic  text  panel  does  not  exist  (e.g.,  security  issues),  the  facilitator 
can  either  rename  an  existing  generic  panel,  or  create  a  brand  new  generic  panel  to  fill 
that  need. 
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The  final  interface  component  involves  the  graphical  diagram  capability.  This 
functionality  is  placed  on  the  last  of  the  tabbed  panels,  and  is  labeled  “Graphical 
Diagram.”  The  graphical  diagram  allows  more  details  to  be  added  to  the  hierarchical 
process  decomposition  contained  in  the  tree  structure  such  as  process  sequence,  decision 
logic,  and  conditional  flow. 

2.5.5  Building  the  PM  Prototype 

2. 5. 5. 1  Deve lopment  Envi ronment 

Java  was  selected  as  the  programming  language  for  the  client  component  of  PM  for  a 
number  of  reasons.  Java  is  object-oriented,  and  has  extensive  built-in  networking 
capabilities  that  allow  for  development  of  distributed  applications.  Java  is  also  portable 
and  architecturally  neutral.  This  means  it  can  be  executed  in  any  environment  that 
supports  Java  applets,  such  as  Windows  NT,  Windows  95/98,  Unix  or  Macintosh. 

2. 5. 5. 2  PM  Object  Model 

The  client  component  of  PM  consists  of  five  different  types  of  objects: 

•  Process  Model  objects  (e.g..  Process,  Actor,  Object,  Link) 

•  GUI  objects  for  regular  users  (e.g.,  TreePanel,  OverViewPanel,  ActorPanel, 

ObjectPanel,  GraphPanel) 

•  Additional  GUI  objects  for  facilitators  (e.g.,  FacilitatorFrame,  UserPrivPanel) 

•  Communication  objects  (e.g..  Client,  ClientEvent,  ClientAdapter,  ClientListener) 

•  Administration  objects  (e.g.,  AdminFrame,  UserList,  SessionList) 

All  the  activities  related  to  process  are  actually  performed  by  the  ProcModel  object. 

Other  objects  are  used  for  GUI,  communication,  or  administrative  control  purposes. 

2. 5. 5. 3  implementation 

When  a  session  is  generated  using  administration  module,  a  sub-directory  for  that  session 
is  automatically  created  on  the  server.  The  six  process-related  tables  are  created  and 
stored  in  that  sub-directory.  Then,  a  user  can  download  the  client  Java  applet  through  the 
Internet  and  log  into  that  session.  A  protocol  based  on  Java  Socket  was  designed  and 
implemented  for  communication  between  the  client  and  the  server.  Before  sending 
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update  requests  to  the  server,  the  client  has  to  request  locks  on  all  related  data  items  from 
the  server  (row-level  locking).  If  the  locking  requests  are  approved,  the  clients  will  send 
an  SQL-embedded  request  to  the  server.  The  server  is  responsible  for  verifying  the  user 
privileges  and  parsing  the  incoming  request.  If  the  user  has  the  right  to  update  the  data 
and  the  request  is  correctly  parsed,  the  appropriate  data  items  in  the  Paradox  database  are 
modified  and  locks  held  by  clients  are  released.  Finally,  the  server  broadcasts  the  change 
to  all  active  clients.  Each  client  will  update  their  local  copy  of  data  and  refresh  the 
process  model  on  the  fly.  PM  can  also  export  a  report  of  the  generated  process  model  in 
HTML  format  by  using  Delphi  Dynamic  Link  Library  (DLL)  calls. 

In  order  to  facilitate  the  communication  among  collaborative  users,  we  also  implemented 
a  tool  called  ‘chat  window’,  which  can  be  activated  from  the  menu  bar.  It  will  pop  up  a 
small  dialog  window  and  the  text  that  is  typed  by  one  user  can  be  echoed  to  others.  All 
the  contents  in  the  chat  window  will  be  stored  in  a  table  on  the  server.  This  tool  was  used 
in  the  field  study  and  proved  helpful  in  the  distributed  collaborative  environment. 

2.5.6  Observing  and  Evaluating  PM 

The  final  stage  in  the  PM  systems  development  research  was  to  observe  and  evaluate  the 
system  to  determine  compliance  with  the  stated  requirements,  assess  its  impact  on  users 
and  groups,  and  identify  desired  improvements.  Results  of  this  evaluation  were  highly 
encouraging.  Users  consistently  rated  PM  over  4  (of  5)  on  ease  of  use. 

2.6  Requirements  for  Dll  COE  Level  5 
The  two  primary  tools  in  the  DOME  system  are  GroupSystems  and  Process  Modeler. 
Since  GroupSystems  is  a  commercial  tool  and  Process  Modeler  is  a  research  prototype 
developed  in  a  very  short  time  frame  with  limited  resources,  investigating  Defense 
Information  Infrastructure  (DII)  Common  Operating  Environment  (COE)  requirements 
was  secondary  to  achieving  primary  DOME  project  goals  within  contract  costs.  In 
general,  the  DOME  environment  was  developed  with  DII  COE  Level  3  (as  seen  in  Table 
2)  as  the  goal  runtime  compliance  level.  The  goal  was  to  ensure  that  environmental 
conflicts  were  resolved  so  that  DOME  components  could  co-exist  on  the  same 
workstation/LAN  as  COE-based  software.  The  degree  of  GroupSystems  and  Process 
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Modeler  runtime  compliance  and  actions  required  to  reach  Level  5  are  briefly 
summarized  below. 


Runtime  Compliance  Level 

GroupSystems 

Process  Modeler 

Level  1  -  Standards  Compliance 

•  Standards  compliance 

•  Partial  (Kernel  only) 

•  Partial  (Kernel  only) 

•  Undisciplined  data  sharing 

•  Minimal 

•  Virtually  none 

•  Software  reuse 

•  Partial  (other  GS  tools) 

•  Partial  (other  Java 
tools) 

Level  2  -  Network  Compliance 

•  Co-exist  on  same  LAN/different  CPU 

•  Yes 

•  Yes 

•  Limited  data  sharing 

•  Minimal  (via  text/RTF) 

•  No 

•  Common  appearance 

•  Yes 

•  Yes 

Level  3  -  Workstation  Compliance 

•  Co-exist  on  same  LAN/workstation 

•  Yes 

•  Yes 

•  Data  sharing  via  common  standards 

•  Generally  no 

•  No 

•  Kernel  COE  resident  on  w/s 

•  Yes 

•  Yes 

•  Use  COE  components 

•  No 

•  No 

Level  4  -  Bootstrap  Compliance 

•  In  segment  format 

•  No 

•  No 

•  Use  bootstrap  COE 

•  Yes 

•  Yes 

•  Separate  application  login  account 

•  Yes 

•  Yes 

Level  5  -  Minimal  Compliance 

•  Share  same  kernel  COE 

•  Yes 

•  Yes 

•  Available  via  Executive  Manager 

•  Yes 

•  Yes 

•  Have  segment  descriptor  files 

•  No 

•  No 

•  Adhere  to  Windows  “look  &  feel” 

•  Yes 

•  Yes 

•  Segments  registered,  in  on-line  library 

•  No 

•  No 

•  Use  COE  installation  tools 

•  No 

•  No 

Table  2.  Process  Modeler  and  Group  Systems  Compliance  Levels 


GroupSystems  is  a  commercial  product  that  was  not  developed  for  the  Department  of 
Defense.  Therefore,  while  GroupSystems  successfully  runs  without  conflict  on  the  same 
workstation/LAN  as  COE-based  software  in  the  DII  COE,  it  does  not  fully  comply  with 
any  of  the  runtime  compliance  levels.  It  does  operate  in  a  Windows  NT  4.0  environment 
(DII  COE  Kernel),  but  does  not  use  some  of  the  other  standard  non-kernel  components 
(e.g.,  MS  Access’s  data  access  services).  However,  it  comes  with  a  built-in  database  as 
part  of  its  installation  package.  It  is  available  via  standard  Windows  run  options  (e.g., 
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Start  Menu,  Desktop  Icon,  Run  command)  and  also  conforms  to  the  basic  “look  and  feel” 
of  the  Windows  graphical  user  interface.  However,  segmenting  has  not  been  performed 
nor  segment  descriptions  developed  IAW  DII  COE  standards.  Nor  does  it  use  COE 
components  or  services.  Although  GroupSystems  does  not  interfere  with  standard 
Windows/LAN  login  security,  a  separate  GroupSystems  login  account  must  be 
established  in  its  administrator  module  and  used  to  login  to  GroupSystems  sessions.  Data 
sharing  is  primarily  between  GroupSystems  tools,  although  some  limited  data  sharing 
with  other  applications  is  possible  using  text  or  RTF  files. 

Modification  of  GroupSystems  to  comply  with  DII  COE  Level  5  requirements  would 
have  to  be  coordinated  with  the  vendor,  Ventana  Corporation.  Ventana  does  regularly 
upgrade  GroupSystems,  keeping  pace  with  the  most  current  Windows  operating  systems 
and  using  Windows  development  standards  as  guidelines.  Therefore,  as  DII  COE 
requirements  move  more  closely  towards  Windows  standards,  GroupSystems  will  more 
closely  comply  with  the  DII  COE  standards.  However,  in  all  likelihood,  Ventana  would 
only  implement  DOD-unique  requirements  if  they  were  directly  paid  to  do  so. 

The  Process  Modeler  client  runs  without  conflict  on  the  same  workstation/LAN  as  COE- 
based  software,  but  primarily  uses  Microsoft’s  Internet  Explorer  4.01  to  run  the  Java 
applet  from  the  server.  This  is  because  Netscape  (the  DII  COE  standard  browser)  did  not 
provide  the  required  level  of  Java  support  until  very  recently.  Although  new  versions  of 
Netscape  (4.5  and  greater)  will  most  likely  run  the  applet,  some  additional  testing  and 
software  modifications  may  be  required  to  ensure  capability.  The  Process  Modeler  server 
operates  under  Windows  NT  and  can  operate  any  web  server.  Therefore,  its  web 
resource  needs  should  always  be  in  line  with  COE-based  software.  However,  the  server 
uses  Borland’s  Database  Engine  (BDE)  for  data  storage  and  access.  The  server  comes 
packaged  with  the  BDE,  and  the  BDE  is  automatically  installed.  No  additional  support  or 
purchasing  is  necessary.  The  client  and  server  have  not  been  segmented  nor  segment 
descriptions  developed  IAW  DII  COE  standards.  COE  components  and  services  are  not 
used.  Like  GroupSystems,  Process  Modeler  has  its  own  login  accounts.  There  is 
virtually  no  data  sharing  except  for  that  provided  by  the  HTML  report  capability. 
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All  modifications  to  Process  Modeler,  both  to  improve  functionality  and  to  comply  with 
DII  COE  Level  5  requirements,  are  contingent  on  funding  availability.  Full  level  5 
compliance  may  require  a  complete  rewrite  of  the  Process  Modeler  server  module,  so  it  is 
probably  not  cost  effective.  In  contrast,  improved  data  sharing,  especially  for 
GroupSystems  import/export,  is  essential  to  provide  adequate  meeting  support.  The 
client  applet  is  by  definition  tied  to  Java  applet  standards  and  is  limited  to  as  much 
compliance  to  COE-standards  as  the  Java  platform  is. 
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3.0  DOME  DEMONSTRATIONS 


3.1  Strategic  Planning  Support 

Strategic  planning  is  an  essential  part  of  establishing  the  Air  Force’s  direction.  Using  a 
distributed  group  support  system  for  strategic  planning  was  one  avenue  to  make  effective 
use  of  technology  and  improve  the  strategic  planning  process.  In  the  United  States  Air 
Force,  quality  is  a  combination  of  leadership  commitment  and  operating  style  that 
inspires  trust,  teamwork  and  continuous  improvement.  According  to  Dettmer  (3)  quality 
has  become  a  necessary  condition,  not  a  discriminator.  At  an  Air  Force  Wing,  quality  is 
a  thinking  process  which  enables  the  entire  unit  to  understand  the  effect  of  local  actions 
and  decisions  on  the  overall  mission  performance. 

Strategic  planning  is  a  process  by  which  the  entire  organization  envisions  the  future  and 
develops  a  plan  to  weave  quality  into  that  future.  One  method  for  an  Air  Force  Wing  to 
accomplish  quality  in  a  strategic  planning  process  is  to  include  a  large  number  of  the 
units  in  the  development  of  the  plan.  Unfortunately,  practical  constraints  such  as  time  or 
scheduling  typically  limit  the  number  of  people  who  can  be  involved  in  a  group  process. 
If  there  are  20  members  of  a  squadron  leadership  team  that  plan  to  work  on  developing 
action  plans  for  15  or  more  measurable  objectives  in  an  eight-hour  period,  the  team 
shares  480  minutes.  That  leaves  32  minutes  for  each  target  and  1 .6  minutes  of  talk  time 
for  each  person  in  the  group.  These  calculations  are  made  without  considering  lunch  or 
breaks  so  the  1 .6  minutes  will  actually  be  less  than  a  minute.  If  a  facilitator  controlled 
the  interaction  so  each  person  in  the  group  had  less  than  1 .6  minutes  to  discuss  an  action 
plan,  the  participants  would  not  have  contributed  much  to  the  discussion  or  the  decision. 
Thus,  there  would  be  difficulty  inspiring  trust  and  enabling  the  unit  to  understand  the 
effects  of  local  actions  on  the  overall  mission. 

Too  often,  strategic  planning  is  treated  as  an  annual  paperwork  exercise  that  has  limited 
effect  on  the  way  organizations  actually  do  business.  Also  the  strategic  planning  process 
can  frustrate  the  individuals  who  devote  so  much  time  to  creating  a  product  that  usually 
only  sits  on  a  shelf.  Few  have  promised  that  strategic  planning  would  be  easy,  nor  is 
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there  a  guarantee  of  success.  The  Air  Force  has  to  be  able  to  adapt  to  change  more 
quickly  than  at  any  other  time  in  history.  But  the  Air  Force  must  do  more  than  just  adapt 
to  change.  It  must  proceed  proactively  to  decide  what  the  future  will  be  and  shape  it. 

The  articulation  of  an  Air  Force  Wing’s  strategic  plan  is  a  mechanism  for  communication 
that  promotes  the  coordination  of  activities  and  goals  across  the  organization.  In  an 
attempt  to  simplify  the  strategic  planning  process,  many  units  in  the  Air  Force  have 
adopted  a  hybrid  of  some  of  the  more  popular  models.  The  culmination  of  models  and 
methods  has  produced  a  model  that  the  366th  Wing  at  Mountain  Home  AFB  used  to 
develop  strategic  plans.  Working  directly  with  General  Peck  and  Lieutenant  Colonel 
Shearer  a  strategic  planning  methodology  was  developed.  The  unit  needed  to  establish  a 
vision  for  the  future,  institute  a  mission  statement,  develop  goals  based  on  the  mission, 
create  objectives  to  meet  the  goals,  establish  targets,  and  write  action  plans  to  guide  the 
unit  in  accomplishing  the  mission  and  goals  of  the  organization.  Target  is  a  term  specific 
to  the  Air  Force’s  planning  approach  and  used  at  the  366th  to  describe  specific  sub¬ 
objectives.  The  targets  are  a  necessary  step  at  he  squadron  level  since  goals  and 
objectives  are  defined  at  the  wing  level  and  are  not  required  to  have  metrics.  Subordinate 
units  at  the  Group  level  specify  sub-objectives  (targets)  and  squadrons  develop  action 
plans  to  meet  the  Wing  goals  and  objectives.  When  a  subordinate  unit  meets  the  metric 
of  a  target  the  Air  Force  Wing’s  strategic  plan  is  a  step  closer  to  completion. 

Electronic  meetings  have  helped  the  Air  Force  adapt  to  change  quickly  by  making  group 
processes  efficient.  Air  Force  strategic  planning  teams  have  met  and  engaged  in  planning 
processes  that  effectively  coordinate  time  and  resources  to  produce  an  optimal  solution. 

A  group  support  system  (GSS)  used  in  conjunction  with  facilitation  expertise  has 
demonstrated  positive  outcomes.  The  following  at  a  few  points  from  the  participants  in 
the  research: 

•  “Use  of  Intranet  made  it  easy  to  allocate  time  to  provide  input  (easy  to  "park" 
while  handling  other  pressing  issues,  and  then  come  back  to  later.”  Time 
Management:  Seamless  start  and  stop  interaction 
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•  ’’Very  useful  tool  for  "jotting  down  ideas”  for  future  use.  Allowed  for  others  to 
view  other  ideas  and  spin  off  if  applicable.  Use  of  modem  technology 
[GroupSystems]  quickened  the  process  and  also  produces  useful  reports  to  work 
from.”  Time  Independent  Idea  Development:  GroupSystems  was  used  to  record 
ideas  as  the  came  up  in  the  course  of  a  workday. 

•  “I  think  it  went  really  well  [the  strategic  planning  session];  however,  with 
utilizing  the  distributed  software  prior  to  today,  time  spent  here  could  have  been 
better  utilized.”  Participation:  All  group  members  did  not  interact  in  the 
distributed  sessions  so  there  was  frustration  when  we  took  f-t-f  time  to  do 
activities  which  should  have  been  done  distributed 

•  “Very  difficult  to  gain  access  from  my  office.”  Procrastination:  Some 
participants  waited  until  the  day  before  the  f-t-f  meeting  to  gain  access  to  the 
session 

•  “Having  access  to  the  system  ahead  of  the  scheduled  strat  planning  session  is 
helpful.”  Pre-work:  Generating  potential  actions  prior  to  the  strategic  planning 
session  was  useful  for  the  group 

GSSs  allowed  large  numbers  of  participants  to  interact  as  teams  across  all  levels  of  an  Air 
Force  Wing.  The  Air  Force  Wing's  squadrons  are  directly  linked  to  the  Wing  Command, 
Wing  Groups  and  Wing  Staff  through  the  computer's  repository.  When  the  group 
interaction  is  anonymous,  the  Airman  has  a  voice  as  loud  as  the  most  senior  officer  does. 
The  GSS  methodology  developed  and  described  previously  allows  the  Air  Force  to 
produce  quality  strategic  plans  with  effective  use  of  resources. 

A  computer-mediated  strategic  planning  process  helps  reduce  the  constraints  associated 
with  bringing  a  large  group  of  people  together  to  collaborate.  Group  support  systems 
(GSS)  are  technology  designed  to  directly  impact  and  change  the  behavior  of  groups  to 
improve  group  effectiveness,  efficiency  and  satisfaction  (Nunamaker,  Dennis,  Valacich, 
Vogel,  &  George,  (6)).  GSSs  have  been  designed  to  reduce  the  effects  of  the  barriers  to 
ideal  group  decision  making  (Adkins,  1994).  According  to  Valacich,  Dennis,  and 
Nunamaker  (9),  "a  group  support  system  (GSS),  is  described  as  an  environment  that 
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contains  a  series  of  networked  computer  workstations  that  enable  groups  to  meet  face-to- 
face,  with  a  computer-supported  electronic  communication  channel  used  to  support  or 
replace  verbal  communication"  (p.  49-50).  When  a  GSS  is  applied  to  group  decision 
making:  (1)  ideas  can  be  exchanged  between  group  members  and  organized  into  distinct 
categories,  (2)  the  categories  can  be  analyzed  by  group  members  exchanging  information 
through  electronic  file  folders,  (3)  consensus  can  be  developed  between  group  members, 
(4)  data  can  be  used  and  reviewed  in  future  meetings,  and  (5)  data  can  be  exported  to  a 
superior  or  expert  for  critique  or  approval. 

GroupSystems  software,  developed  at  the  University  of  Arizona,  supports  several 
different  group  tasks.  The  standard  GSS  decision  sequence  is  a  five-stage  process.  First, 
a  group  leader  meets  with  a  facilitator  to  set  an  agenda  for  the  meeting  and  decide  which 
GroupSystems  tools  to  use.  Second,  meetings  usually  begin  with  group  members 
generating,  exchanging,  and  evaluating  ideas.  Third,  the  ideas  are  organized  into  a 
manageable  framework  of  distinct  categories.  Fourth,  group  members  critique  the 
categories.  The  emphasis  in  this  stage  is  to  understand  the  category  and  develop  plans  for 
how  to  activate  the  category.  Fifth,  group  members  attempt  consensus  building. 

A  meeting  facilitator  has  multiple  roles  during  a  meeting  (Brashers,  Adkins,  &  Meyers, 
(2),  Nunamaker,  et  al.,  (6)).  For  example,  the  facilitator  may  be  the  group  leader,  a  group 
member,  or  an  individual  that  is  separate  from  the  group  and  neutral  by  decree.  In  most 
of  the  meetings  that  use  GSS  at  the  University  of  Arizona  the  facilitator  is  not  a  member 
of  the  group.  Meeting  participants  and  organizational  members  can  also  facilitate  GSS 
sessions.  The  role  of  the  facilitator  is  to  provide  technical  support,  plan  an  agenda, 
maintain  an  agenda,  and  set  ongoing  standards  for  how  the  GSS  is  used  in  an 
organization  (Nunamaker  et  al.,  (6)).  If  an  organization  does  not  have  a  trained 
facilitator,  the  ActionPlanner  and  SenseMaker  templates  can  be  used  to  help  organize  and 
run  a  GSS  session. 

Typically  the  facilitator's  first  encounter  with  the  group  is  with  the  group's  leader  before 
the  group  meets.  The  facilitator  and  the  group  leader  meet  prior  to  the  actual  meeting  to 


41 


discuss  the  purpose  of  the  meeting  and  make  a  plan  to  blend  the  GSS'  tools  with  the 
intended  goals  for  the  meeting.  A  product  from  this  meeting  is  a  detailed  script  that 
outlines  the  structure  of  the  group’s  meeting.  The  script  indicates  the  specific  phrasing  of 
the  questions  or  topics  that  will  be  addressed  during  the  meeting,  the  group  support 
system  software  tools  that  will  be  used  and  the  length  of  time  each  tool  is  to  be  used  by 
the  group.  After  the  preplan  meeting  the  facilitator  mediates  between  the  structure  of  the 
preplan  script  and  the  actual  group  interaction  by  setting  up  the  GSS'  software  tools  and 
monitoring  the  group's  process  during  the  group's  meeting. 

When  the  group  meets  at  the  group  support  system  facility  the  facilitator  introduces  the 
group  to  the  tools  and  explains  how  the  interaction  is  going  to  proceed.  After  introducing 
the  tools,  the  facilitator  explains  the  question  or  topic  that  is  going  to  be  addressed  and 
discusses  the  structure  of  the  meeting  with  the  group.  For  example,  the  facilitator  may 
tell  the  group  that  the  EBS  tool  will  be  used  to  analyze  the  criteria  against  which  Wing 
goals  will  be  rank  ordered.  The  technical  role  of  the  facilitator  is  to  set  up  the  software 
with  the  specific  criteria  and  tell  the  group  how  EBS  works.  That  is,  tell  the  group  that  all 
the  ideas  are  submitted  anonymously  (if  that  option  is  going  to  be  used).  Explain  how 
EBS  randomly  passes  each  individual’s  ideas  around  to  different  group  members,  how  a 
group  member  can  comment  on  another  group  member's  idea  and  then  pass  the  original 
idea  with  comment  on  to  another  group  member. 

As  a  process  monitor  the  facilitator  keeps  track  of  how  long  the  group  has  been  using  a 
tool,  suggests  ways  to  increase  productivity  when  using  the  tool,  and  tells  the  group  when 
to  move  on  to  another  tool.  The  role  of  the  facilitator  is  multifaceted.  On  one  hand,  a 
facilitator  needs  to  have  the  technical  knowledge  and  skill  to  use  the  tools  provided  in  a 
GSS.  On  the  other  hand,  a  facilitator  needs  to  be  able  to  communicate  with  the  group's 
leader  to  develop  an  agenda  that  meets  the  group's  goals  and  to  perform  the  agenda  at  the 
meeting.  In  an  ideal  situation  determining  the  goal  of  the  meeting  and  designing  the 
process  that  the  group  should  go  though  to  achieve  the  desired  outcome  should  be  simple, 
but  in  actuality  it  is  a  complex  communication  task. 
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A  case  study  was  conducted  at  the  366th  Wing  on  computer-supported  strategic  planning. 
A  facilitation  methodology  for  Air  Force  strategic  planning  was  established  using  senior 
leadership  at  the  366th  Wing.  The  outline  of  the  methodology  is  to  first,  work  a  two-day 
offsite  meeting  with  senior  leadership  in  a  small  group  of  eight  to  establish  the  mission, 
vision,  goals,  and  broad  objectives  of  the  Wing.  Second,  work  a  one  day  meeting  at  the 
group  level  to  establish  strategic  targets  based  on  the  Wing’s  objectives.  Third,  work 
one-day  meetings  at  the  squadron  level  to  develop  measurable  action  plans  based  on  the 
Group’s  targets. 

At  the  366th  Wing  there  is  a  Wing  Command  and  5  group  level  units,  Wing  Staff  (WG), 
Operations  Group  (OG),  Logistics  Group  (LG),  Support  Group  (SPTG),  and  Medical 
Group  (MDG).  Each  group  is  responsible  for  a  number  of  squadrons  and  there  are  24 
squadrons  in  the  366th  Wing.  CMI  worked  with  the  366th  Wing  command,  three  groups 
(OG,  LG,  and  SPTG),  the  366th  Wing  staff,  and  seven  squadrons  using  computer- 
supported  strategic  planning  methods  and  a  group  support  system  (GSS).  The  specific 
GSS  method  is  explained  in  detail  in  the  following  paragraphs.  After  the  strategic  plan 
was  developed,  seven  external  Quality  Improvement  officers  evaluated  24  squadron  level 
strategic  plans.  Quality  questionnaires  were  administered  to  all  squadrons  (alpha=.93). 
Open-ended  data  were  collected  from  squadrons  using  both  traditional  and  computer- 
supported  strategic  planning  methods.  All  squadron  action  plans  were  evaluated  by  a 
panel  of  seven  experts  using  a  quality  scale  (alpha  =  .94). 

The  computer  supported  strategic  planning  accomplished  by  the  366th  Wing  included 
three  major  areas:  1)  Wing  level  strategic  planning,  2)  Group  level  strategic  planning,  and 
3)  Squadron  level  action  planning.  At  the  Wing  level,  members  of  the  Wing  Command 
met  offsite  and  used  a  deployable  LAN  consisting  of  networked  laptop  computers 
running  Novel  NetWare  and  GroupSystems.  The  process  to  conduct  the  computer- 
supported  strategic  planning  session  included:  the  discussion  of  the  function  of  mission 
and  vision  statements  on-line;  review  of  1996  mission  and  vision  statements  in  parallel 
with  the  other  participants;  group  authoring  of  new  mission  and  vision  statements;  the  use 
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of  a  nominal  group  technique  and  anonymous  voting  to  select  the  final  statements  for  the 
Wing. 

The  Wing  Command  then  brainstormed  ideas  for  Wing  goals  using  the  previously 
developed  mission  and  vision  statements  as  a  guide.  Anonymous  voting  on  the  goals  and 
refinement  of  the  highest  rated  goals  resulted  in  a  final  list  of  goals,  which  were  used  as  a 
basis  for  the  development  of  Wing  objectives  (Figure  7). 
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Figure  7.  Using  Categorizer  and  Criteria  to  Develop  Objectives 

The  Wing  goals  were  placed  in  a  hierarchical  tree  structure  so  those  objectives  that 
supported  each  goal  could  be  generated  in  parallel.  The  objectives  were  reviewed  against 
three  criteria  that  had  been  developed  previously:  1)  This  is  not  an  objective,  but  is  a 
candidate  for  Group  level  review,  2)  This  is  an  objective  that  requires  additional  work,  or 
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3)  This  is  an  objective  as  written.  The  GroupSystems  Categorizer  was  used  to 
accomplish  this  task. 

The  Group  Level  strategic  planning  was  accomplished  in  similar  fashion.  A  tree 
structure  of  Wing  goals  and  objectives  was  presented  to  the  Group  staff  members  for 
each  of  the  Groups.  Each  Group  staff  developed  targets  in  parallel  and  reviewed  them 
against  three  criteria:  1)  This  is  not  a  Group  level  target,  2)  This  is  a  Group  level  target 
that  requires  work,  or  3)  This  is  a  Group  level  target  as  written.  The  targets  were  refined 
as  needed  and  the  group  then  moved  on  to  the  next  objective.  Once  again,  the  Vote  and 
Categorizer  tools  were  used  to  accomplish  these  tasks. 

CMI  has  created  and  fielded  a  set  of  robust  collaborative  application  prototypes  to 
enhance  the  performance  of  teams  thinking  towards  a  decision  or  common  goal.  The 
result  of  the  work  that  has  been  on-going  for  two  decades  is  now  embodied  in 
GroupSystems,  a  suite  of  collaborative  software  tools  market.  Those  tools  are  described 
below: 


The  Standard  Tools  [of  GroupSystems]  support  business  needs  such  as 
strategic  planning,  activity  based  costing,  business-process  reengineering, 
innovative  problem  solving,  product  definition,  knowledge  management, 
and  many  more.  To  support  these  needs,  the  Standard  Tools  use  group 
processes  such  as  brainstorming,  list  building,  information  gathering, 
voting,  organizing,  prioritizing,  and  consensus  building. 

Categorizer  helps  your  group  generate  a  list  of  ideas  and  supporting 
comments.  You  then  create  categories  for  the  ideas  and  easily  sort  the 
ideas  and  comments  into  the  desired  categories. 

Electronic  Brainstorming  provides  a  simple  process  in  which  a  question 
or  issue  is  distributed  to  participants,  who  respond  with  comments.  It 
promotes  creative  and  far-reaching  discussions. 
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Group  Outliner  allows  the  group  to  create  and  comment  on  a  multi-level 
list  of  topics.  Structure  lines,  bullets,  or  a  legal  numbering  format 
represents  levels  of  subordination. 

Topic  Commenter  offers  participants  the  opportunity  to  comment  on  a 
list  of  topics.  This  tool's  format  for  idea  generation  is  more  structured 
than  Electronic  Brainstorming,  but  less  structured  than  Group  Outliner. 

Vote  provides  a  variety  of  methods  which  help  the  group  evaluate  a  list  of 
ideas  to  develop  consensus  or  reach  a  decision.  The  results  can  be 
displayed  in  statistical  and  graphic  formats. 

You  can  also  customize  your  GroupSystems  installation  with  the  add-in 
tools  that  you  need.  The  following  add-ins  can  be  purchased  with  the 
GroupSystems  Standard  Tools  or  as  standalone  applications. 

Survey  expands  the  horizons  of  on-line  surveys.  Use  Survey  for  face-to- 
face  or  distributed  groups  across  local  area  networks,  e-mail,  the  Internet, 
or  your  company's  intranet  —  and  then  collect  and  analyze  results  with 
push-button  ease. 

Alternative  Analysis  allows  your  group  to  explore  the  strengths  and 
weaknesses  of  strategic  plans,  select  candidates,  determine  the  impact  of  a 
plan  on  stakeholders,  generate  and  prioritize  product  requirements  —  and 
much,  much  more. 

Activity  Modeler,  the  first  team-based  modeling  tool,  allows  a  team  to 
work  directly  and  simultaneously  on  a  graphical  model  of  business 
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processes  —  so  you  can  quickly  and  easily  redesign  the  way  your  business 
operates.1 

GroupSy  stems  software  is  used  in  a  GSS  and  was  developed  at  the  University  of  Arizona. 
GroupSystems  software  supports  several  different  group  tasks.  This  paper  will  focus  on 
the  support  tools  that  are  directly  related  to  the  process  of  computer-supported  strategic 
planning.  According  to  Nunamaker,  Dennis,  Valacich,  Vogel,  and  George  (1991)  there  is 
a  common  sequence  of  GSS  use  that  is  coupled  with  specific  software  tools.  The 
standard  GSS  decision  sequence  is  a  five-stage  process.  First,  a  group  leader  meets  with 
a  facilitator  to  set  an  agenda  for  the  meeting  and  decide  what  GroupSystems  tools  to  use. 
Second,  meetings  usually  begin  with  group  members  generating,  exchanging,  and 
evaluating  ideas.  Third,  the  ideas  are  organized  into  a  manageable  framework  of  distinct 
categories.  Fourth,  group  members  critique  the  categories.  The  emphasis  in  this  stage  is 
to  understand  the  category  and  develop  plans  for  how  to  activate  the  category.  Fifth, 
group  members  attempt  consensus  building. 

Typically,  groups  use  an  electronic  brainstorming  (EBS)  tool  to  generate  ideas.  The  tool 
is  designed  for  group  members  to  type  in  comments  on  a  specific  question  shown  on  their 
screens.  Once  a  group  member  enters  in  a  comment  the  idea  is  randomly  passed  on  to 
another  group  member.  In  addition,  a  list  of  all  the  ideas  can  be  shown  on  the  large 
screen  in  the  front  of  the  room  and  at  each  individual  workstation.  This  tool  is  designed 
to  allow  group  members  to  build  on  others'  ideas  without  evaluation.  Also,  the  tool  can 
make  all  the  comments  submitted  to  the  group  anonymous. 

In  addition  to  EBS,  there  are  two  other  tools  that  can  be  used  for  idea  generation  and 
evaluation.  The  first  tool  is  topic  commenter  (TC).  This  tool  functions  like  a  set  of  index 
cards  with  topics  written  across  the  top  of  each  card.  A  participant  selects  a  specific  topic 
card,  enters  comments  and  reads  the  comments  submitted  by  other  group  members.  The 
second  tool,  group  outliner  (GO)  is  very  similar  to  TC  but  GO  allows  the  group  members 


1  Website  of  Ventana  Corporation,  a  technology  transfer  company  of  the  CMI:  www.ventana.com 
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to  develop  multiple  sets  of  index  cards  in  an  indented  outline  structure.  Usually,  but  not 
always,  TC  or  GO  are  used  after  EBS  as  an  organizational  tool. 

The  idea  generation  tools,  EBS,  TC,  and  GO,  are  engineered  to  reduce  the  traditional 
constraints  of  a  face-to-face  meeting  such  as  status  pressure  and  turn  taking  obstacles. 
GSS  provides  a  bridge  over  status  and  turn  taking  barriers  so  groups  can  develop 
exhaustive  lists  of  ideas  and  solutions  that  solve  problems  and  answer  the  group's 
questions. 

Additional  idea  organization  can  be  done  with  the  categorizer  tool.  This  tool  provides  a 
two-  phase  approach  to  idea  organization.  First,  the  tool  allows  group  members  to 
develop  and  analyze  a  list  of  categories  and  supporting  ideas  for  each  category  in  a 
number  of  different  windows.  New  ideas  can  be  generated  with  this  tool  and  ideas  from 
the  EBS  session  can  be  incorporated  into  different  categories.  Second,  the  categories  and 
the  various  supporting  ideas  in  each  category  are  consolidated.  The  consolidation 
process  involves  verbal  interaction  between  the  facilitator  and  the  group  members.  The 
categories  are  usually  analyzed  for  redundancy  and  combined  into  new  or  existing 
categories  without  deleting  ideas. 

After  the  categories  have  been  created  and  analyzed  the  group  attempts  to  build  a 
consensus  by  using  prioritizing  tools.  There  are  a  variety  of  methods  available  to  rank 
categories  (e.g.,  yes/no,  multiple  choice,  and  rank  order).  Alternative  analysis  enables  the 
group  to  rate  the  alternatives  in  a  multi-dimensional  matrix  then  presents  the  results  to  the 
group  on  their  individual  screen  and  on  the  large  projection  screens  in  front  of  the  room. 
Group  survey  allows  each  group  member  to  fill  out  an  electronic  questionnaire.  The 
questionnaire  is  usually  pre-constructed  and  designed  to  assess  either  a  specific 
characteristic  of  the  group  (e.g.,  cohesiveness,  level  of  group  trust)  or  information  about 
the  available  alternatives  (e.g.,  are  you  satisfied  with  the  alternatives).  A  group  facilitator 
operates  most  of  the  GroupSystems  tools  and  GSS  technology. 
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The  Squadron  Level  action  planning  for  each  of  the  seven  squadrons  utilizing  the  GSS 
followed  a  methodology.  The  methodology  included  a  review  of  the  action  plan 
definition,  review  of  the  function  of  an  action  plan,  discussion  of  the  action  plan 
template,  review  of  the  Wing  and  Group  goals,  objectives,  and  targets,  development  of 
potential  action  plans  in  parallel,  and  finally  comparison  of  action  plans  to  criteria. 

Action  plans  were  defined  as  a  link  between  day-to-day  work  place  activities  and  the 
vision,  mission,  goals,  and  objectives  of  the  Wing.  Action  plans  should  meet  the  needs  of 
the  squadron  while  being  simple  and  easy  to  apply.  They  also  had  to  be  directed  at 
processes  that  could  be  measured,  analyzed,  and  improved.  The  design  of  the  action 
plans  was  such  that  they  were  implementable,  acceptable,  and  attainable.  The  action  plan 
template  used  included  a  description,  metric,  milestone,  success  criteria,  responsible 
authority,  resource  identification,  and  feedback  mechanism. 

Participants 

There  were  226  participants  from  the  366th  Wing.  At  the  squadron  level  there  were  139 
participants  (Males=105,  Females=21,  n/a=13).  The  mean  age  of  the  squadron 
participants  is  M=35.4  and  a  range  of  21  to  56  year  of  age.  The  majority  of  the  squadron 
participants  had  participated  in  one  or  less  computer  supported  meetings  (N=107). 
Representatives  from  22  of  24  squadrons  participated  in  the  research  project.  Seven 
squadrons  (N=92)  used  computer-  supported  strategic  planning  methods  and  17 
squadrons  (N=47)  used  traditional  strategic  planning  methods.  There  was  a  panel  of 
seven  external  Quality  Improvement  officers  used  to  review  the  squadron’s  action  plans. 
The  reviewers  have  a  mean  of  M=20.1  years  of  service  in  the  Air  Force  and  a  mean  of 
M=2.96  years  working  on  strategic  planning. 

Dependent  Variables 

A  six  item  quality  questionnaire  (alpha=.94)  was  created  for  the  reviewers  to  evaluate  the 
action  plans  each  squadron  developed.  The  reviewers’  questionnaire  measured  the 
quality  of  the  action  plans,  achievability,  buy-in,  how  well  the  action  plans  addressed  the 
targets,  and  how  clear  the  plans  are  measured.  The  26  item  satisfaction  questionnaire 
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(alpha=.93)  measured  satisfaction  with  the  strategic  planning  process  and  commitment  to 
the  strategic  plans  produced.  Time  to  completion  was  measured  via  a  questionnaire  and 
actual  measurement. 

Results 

The  squadrons,  which  used  group  support  systems  (GSS)  to  develop  strategic  plans, 
developed  higher  quality  strategic  plans  than  those  squadrons  that  did  not  use  GSS 
(t(7)=3.47,  p<.05).  There  was  no  significant  difference  for  commitment  to 
implementation  between  the  GSS  and  the  non-GSS  squadrons.  Squadrons  that  used 
computer-supported  strategic  planning  where  more  satisfied  with  the  strategic  planning 
process  than  those  squadrons  that  used  traditional  strategic  planning  (t(137)=-2.28, 
p<.05).  The  strategic  planning  process  took  an  average  of  17.7  hours  for  squadrons  that 
did  not  use  GSS  and  less  than  8  hours  for  those  squadrons  that  used  GSS. 

The  external  evaluation  of  the  quality  of  the  squadrons’  strategic  plans  provides  a  strong 
indication  that  strategic  plans  created  with  computer-support  are  higher  in  quality  than 
those  strategic  plans  produced  without  the  use  of  GSS.  In  addition  to  high  quality,  the 
computer-supported  strategic  plans  addressed  the  Group’s  targets  well  and  provided  an 
action  plan  that  had  a  specific  measurable.  Squadrons  that  used  the  computer-supported 
strategic  planning  methodology  saw  an  increase  in  satisfaction  with  the  overall  strategic 
planning  process.  Also,  there  was  a  significant  increase  in  the  number  of  ideas  generated 
and  incorporated  into  the  process  as  compared  to  traditional  face-to-face  strategic 
planning.  The  increase  in  satisfaction  with  the  process  should  lead  to  higher  quality 
strategic  plans  and  greater  more  detailed  participation  in  the  planning  process. 

Less  time  was  used  to  develop  action  plans  when  the  computer-supported  strategic 
planning  methodology  was  used.  The  non-GSS  squadrons  used  perceptual  data  and  the 
GSS  groups’  used  actual  data  regarding  time  to  completion.  These  data  are  fair  to 
compare  as  several  GSS  users  commented,  in  open-ended  questionnaires,  on  how  fast  the 
strategic  planning  went  when  they  used  GSS.  In  the  past,  GSS  have  been  shown  to  take 
advantage  of  parallel  processing  and  decrease  the  time  to  completion  so  it  seems 
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reasonable  that  the  same  results  are  found  in  this  case  study.  There  was  not  a  significant 
difference  between  GSS  andNon-GSS  groups  regarding  commitment  to  implementation. 
When  a  participant  is  asked,  “I  am  compelled  to  implement  the  action  plan,”  the  squadron 
members’  Air  Force  training  should  dominate  the  group’s  thinking  and  the  squadron 
should  be  committed  to  the  strategic  plan  regardless  of  how  the  plan  was  developed. 

Overall  the  study  provides  support  for  the  claim  that  computer-supported  strategic 
planning  can  assist  the  United  States  Air  Force  in  planning  for  the  future.  Computer- 
supported  strategic  planning  allowed  a  Wing  of  several  thousand  people  to  meet  and 
develop  a  holistic  strategic  plan  in  less  than  three  months.  Computer-supported  strategic 
planning  allowed  each  level  of  the  wing  to  build  on  previous  level’s  ideas  and  comments. 
GSS  allowed  hundreds  of  people  to  be  directly  involved  the  strategic  planning  process. 
Involving  large  numbers  of  personnel  in  the  planning  process  helps  produce  a  high 
quality  product  that  could  not  be  developed  practically  using  traditional  face-to-face 
methodology.  Computer-supported  strategic  planning  assisted  the  United  States  Air 
Force  in  developing  higher  quality  strategic  plans  in  less  time  than  traditional  strategic 
planning  methods. 

Future  Directions 

The  computer-supported  strategic  planning  methodology  needs  to  be  tested  using 
multiple  facilitators  at  a  number  of  different  United  States  Air  Force  Bases.  The 
additional  testing  will  provide  generalizabilty  for  the  computer-supported  strategic 
planning  methodology.  In  addition,  researchers  should  work  with  Wing  staffs  and 
Groups  to  improve  on  the  strategic  planning  process  developed  in  this  study. 

Investigators  should  focus  on  the  link  between  objectives  to  targets  and  action  plans.  The 
link  between  these  items  is  critical  to  developing  a  Wing  wide  strategic  plan. 

3.2  AFTO  107  Process  Improvement 

The  purpose  of  the  DOME  Technology  Demonstration  was  to  showcase  how  the  DOME 
prototype  system  could  be  successfully  used  to  improve  an  existing  Air  Force  process. 
The  process  selected  for  the  technology  demonstration  was  the  AFTO  107  Request  for 


51 


Technical  Assistance  process  used  by  Air  Force  units  to  request  depot-level  repair 
assistance.  The  key  participants  in  the  demonstration- were  the  366th  Wing  at  Mountain 
Home  and  Wamer-Robins  Air  Logistics  Center  AFTO  107  managers  and  engineers 
involved  in  repair  of  the  F- 15  aircraft.  Representatives  of  two  Air  Force  major 
commands  (MAJCOMs)  and  several  other  F-15  units  also  participated  during  the 
demonstration  and  background  interviews.  The  demonstration  was  conducted  over  a 
series  of  three  face-to-face  and  distributed  meetings  to  explore  the  strengths  and 
weaknesses  of  the  DOME  prototype  system  in  each  of  these  environments. 

A  detailed  description  of  the  technology  demonstration  is  provided  in  the  following 
sections.  The  first  section  briefly  describes  the  meetings  and  interviews  held  throughout 
the  DOME  project  to  gather  preliminary  information  about  the  AFTO  107  process.  Each 
of  the  technology  demonstration  meetings  is  then  discussed  individually.  The  costs  and 
benefits  of  the  proposed  DOME  methodology  are  then  presented,  followed  by  a  summary 
of  the  results  of  the  technology  demonstration.  The  process  descriptions  and  models  are 
included  in  the  appendices:  the  “as-is”  model  is  in  Appendix  A,  and  the  “to-be”  model  is 
in  Appendix  B. 

3.2.1  Background 

During  the  initial  phase  of  the  DOME  project,  GroupSy  stems  meeting  rooms  were 
installed  at  Mountain  Home  and  Robins  Air  Force  Bases.  These  GroupSystems 
capabilities  were  used  during  face-to-face  meetings  to  gather  the  initial  information  about 
the  AFTO  107  Request  for  Technical  Assistance  process.  At  Mountain  Home,  CMI 
researchers  facilitated  a  group  of  wing  and  logistics  support  personnel  in  the  development 
of  a  detailed  activity  model  of  the  wing  AFTO  107  process.  Similarly,  CMI  researchers 
worked  with  AFTO  107  managers  and  engineers  at  Warner  Robins  Air  Logistics  Center 
to  develop  an  activity  model  of  the  depot  AFTO  107  process.  GroupSystems  Activity 
Modeler  was  used  to  support  collaborative  model  development  during  both  these 
meetings.  Interviews  were  also  conducted  with  AFTO  107  personnel  at  the  Air  Combat 
Command  to  develop  an  informal  model  of  the  MAJCOM  process  and  at  Seymour- 
Johnson  and  Tyndall  Air  Force  Bases  to  identify  local  differences  in  the  wing  AFTO  107 
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processes.  In  preparation  for  the  technology  demonstration,  CMI  researchers 
consolidated  these  models  into  a  strawman  AFTO  107  process  model  that  became  the 
starting  point  for  the  technology  demonstration. 

3.2.2  Phase  1:  Same  Time,  Same  Place  Meeting 

The  first  phase  of  the  DOME  Technology  Demonstration  was  a  same  time  same  place 
meeting  held  at  the  University  of  Arizona  in  Tucson,  Arizona,  on  19  -  21  October  1998. 
This  meeting  is  described  in  detail  by  first  providing  an  overview  of  the  specific  meeting 
task,  group  participants,  meeting  context,  and  technology,  followed  by  a  more  detailed 
discussion  of  the  meeting  process  and  outcome. 

Task 

The  primary  task  was  to  validate  and  refine  the  strawman  AFTO  107  process  model  so 
that  it  accurately  represented  the  process  from  the  depot,  MAJCOM,  and  wing 
viewpoints.  To  accomplish  this  task,  participants  defined/validated  each  required  action, 
provided  a  short  name  and  a  complete  description  for  those  actions,  determined  the  event 
that  triggered  each  action  to  start,  identified  who  was  responsible  for  performing  the 
action,  and  highlighted  critical  resources  required  to  complete  the  action.  After 
completing  the  process  model,  participants  briefly  identified  problems  with  the  AFTO 
1 07  process  to  begin  the  process  improvement  task  planned  as  the  focus  of  the  next 
meeting. 

Group 

Six  Air  Force  personnel  actively  participated  in  the  meeting.  A  seventh  Air  Force 
attendee  observed  the  meeting  as  a  representative  of  the  Air  Force’s  DOME  contracting 
office.  Air  Force  meeting  participants  included  a  logistician  and  engineer  from  Mountain 
Home  AFB,  the  F- 15  AFTO  107  manager  and  a  reengineering  specialist  from  Wamer- 
Robins  Air  Logistics  Center,  and  F-15  maintenance  managers  from  two  Air  Force 
MAJCOMs  (ACC  and  AETC).  Participants  were  military  and  civilian  employees  with 
over  20  years  experience,  including  an  average  of  over  12  years  with  the  AFTO  107 
process.  Most  participants  had  limited  familiarity  with  the  DOME  project,  with  only  one 
participating  in  the  earlier  meetings.  While  all  participants  used  computers  at  least 
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several  times  a  day  and  had  good  experience  with  an  Internet  browser,  they  reported 
limited  to  no  GroupSystems  or  modeling  experience. 

Three  CMI  researchers  facilitated  and  observed  the  meeting.  Two  of  these  researchers 
had  participated  in  at  least  some  of  the  earlier  information  gathering  meetings  so  they 
were  familiar  with  the  basics  of  the  AFTO  107  process. 

Context 

This  initial  meeting  of  the  technology  demonstration  was  conducted  as  a  face-to-face 
meeting  using  a  large  permanent  GroupSystems  meeting  facility  at  the  University  of 
Arizona.  The  CMI  technical  staff  provided  the  support  required  to  ensure  that  the 
hardware,  software,  and  communication  network  operated  smoothly  throughout  the 
meeting.  All  systems  were  fully  tested  and  problems  resolved  well  before  meeting 
participants  arrived. 

All  Air  Force  participants  traveled  from  their  home  bases  in  Idaho,  Georgia,  Virginia, 
Texas,  and  Ohio  to  attend  the  meeting. 

Technology 

The  facilitators  and  all  meeting  participants  used  personal  computers  connected  to  a  local 
area  network  (LAN),  and  through  the  LAN,  to  the  Internet.  Three  public  screens  were 
connected  to  the  facilitators’  workstations  and  other  display  equipment.  The  primary 
software  used  during  the  meeting  was  the  new  Process  Modeler  prototype  developed 
under  the  DOME  contract.  Process  Modeler  is  designed  as  a  client-server  application  for 
use  in  face-to-face  and  distributed  environments.  The  Process  Modeler  server  is  located 
at  the  University  of  Arizona  and  communicates  with  both  local  and  remote  clients  via  the 
Internet.  Users  downloaded  the  Process  Modeler  client  software  and  a  copy  of  the  AFTO 
107  process  model  using  Microsoft’s  Internet  browser,  Internet  Explorer,  version  4.01. 

As  described  in  the  following  section,  GroupSystems  was  also  used  at  the  beginning  and 
end  of  the  meeting.  Each  participant’s  GroupSystems  workstation  was  directly  connect 
via  the  LAN  to  the  meeting  room’s  local  GroupSystems  server. 
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Process 


The  meeting  began  with  the  Air  Force  project  manager  and  CMI  researchers  providing  a 
brief  overview  of  the  DOME  project  and  the  goals  of  the  DOME  technology 
demonstration.  CMI  researchers  then  presented  the  specific  goals  for  this  meeting  and 
general  meeting  guidelines,  and  had  all  meeting  participants  introduce  themselves  to  the 
group.  After  the  introductions,  CMI  researchers  requested  that  participants  sign-in  using 
GroupSystems  Topic  Commenter.  The  purpose  of  this  exercise  was  twofold:  (1)  to 
develop  an  accurate  participant  roster,  and  (2)  to  introduce  GroupSystems  to  the 
participants. 

The  Process  Modeler  prototype  was  introduced  next  using  a  simple  model  that  described 
the  steps  required  to  prepare  and  go  on  Temporary  Duty  (“Go  TDY”).  CMI  researchers 
provided  brief  instructions  on  the  three  main  components  of  the  Process  Modeler: 

1 .  Process  Hierarchy  -  A  hierarchical  (tree)  view  shows  how  a  process  is 
decomposed  into  sub-processes  and  then  further  into  individual  actions  required 
to  accomplish  each  process/sub-process.  Each  node  in  the  process  hierarchy  is 
given  a  short  action  name  of  the  form  “verb  +  object,”  e.g.,  “Request  Travel 
Orders.”  Note:  Each  node  in  the  process  hierarchy,  regardless  of  whether  it 
represents  a  process,  sub-process,  or  action,  is  generically  referred  to  as  a  process. 

2.  Process  Information  Panels  —  A  series  of  panels,  each  panel  capturing  a  different 
type  of  information  about  a  process,  e.g.,  its  description,  resource  requirements, 
triggering  event,  or  actor  responsible  for  accomplishing  the  action.  A  set  of 
panels  is  associated  with  each  process  (node)  in  the  process  hierarchy.  Panels  are 
displayed  for  the  process  currently  highlighted  in  the  hierarchical  (tree)  view. 

3.  Graphical  Process  Model  -  A  graphical  view  of  the  process  model  showing 
sequence  and  flow  of  the  actions.  Each  process  node  in  the  hierarchical  (tree) 
view  is  automatically  shown  on  the  diagram  using  graphical  conventions  for  the 
Unified  Modeling  Language’s  Activity  Diagram.  Participants  may  then  link  these 
nodes  together  to  reflect  action  sequence  and  decision  flow.  The  Process  Modeler 
automatically  redraws  the  diagram  to  reflect  the  action  sequence  identified  by  the 
participants. 
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Instructions  were  also  provided  on  how  to  add/modify  nodes  in  the  process  hierarchy  and 
add/modify  textual  information  to  the  process  information  panels.  Participants  practiced 
these  actions  by  modifying  the  sample  “Go  TDY”  process  model  to  more  accurately 
reflect  their  actual  (or  desired)  TDY  process. 

CMI  researchers  then  used  the  Process  Modeler  and  led  the  group  through  a  high-level 
review  of  the  strawman  integrated  AFTO  107  process  model.  As  described  in  the 
background  section,  this  model  was  consolidated  from  the  individual  wing,  depot,  and 
MAJCOM  activity  models  developed  during  earlier  meetings  and  interviews.  All 
participants  could  view  the  AFTO  107  process  modeler  on  their  individual  workstations 
and  on  the  public  screen. 

Participants  then  worked  individually  (or  in  pairs  with  the  other  representative  from  their 
organization)  to  refine  the  process  model  by  adding  new  processes  left  out  of  the  original 
model,  modifying  process  names  to  improve  clarity,  and  adding  process  descriptions 
whenever  they  were  missing.  The  role  names  of  individuals  responsible  for  each  process 
were  also  identified.  Although  all  participants  reviewed  the  entire  model,  participants 
primarily  focused  on  improving  their  portion  of  the  model  (e.g.,  depot  personnel  worked 
on  depot  processes).  CMI  researchers  assisted  participants  whenever  they  had  problems 
with  the  Process  Modeler,  but  most  participants  seemed  to  find  the  tool  easy  to  use. 

There  was  some  confusion,  however,  on  the  difference  between  adding/editing  actors  on 
the  master  actor  list  and  adding/deleting  actors  from  a  specific  process.  This  confusion 
highlighted  a  need  to  improve  the  Process  Modeler’s  user  interface  for  the  Actor  Panel  to 
clearly  distinguish  between  these  two  actions.  Regardless  of  these  problems,  all 
participants  were  able  to  assign  actors  to  processes  after  some  additional  instruction. 

The  next  step  in  the  process,  group  review  of  the  AFTO  107  process  model  to  ensure 
consensus,  was  a  challenge  because  of  the  number  of  processes  and  the  several  different 
categories  of  information  captured  for  each  process.  CMI  researchers  decided  to  review 
the  processes  and  their  descriptions  during  the  first  pass  through  the  model  so  that  the 
group  could  initially  focus  on  identifying  all  process  actions  correctly.  During  this 
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review,  true  integration  of  the  model  occurred  as  the  group  worked  together  to  ensure  that 
every  action  by  one  location  had  an  appropriate  response  at  another  location.  Also,  the 
group  checked  that  valid  responses  were  identified  for  each  feasible  action  outcome  (e.g., 
accept  or  reject).  Several  processes  were  added  during  the  review  based  on  these  criteria. 
Missing  or  incomplete  descriptions  were  also  corrected.  Processes  were  then  reviewed  to 
ensure  that  actors  were  correctly  identified  for  all  sub-processes  and  individual  actions. 
Next,  triggers  were  validated  for  all  high-level  and  non-sequential  processes.  The  group 
did  not  bother  to  identify  triggers  for  purely  sequential  actions  when  the  trigger  was 
obvious  -  simply  the  completion  of  the  previous  action.  The  graphical  view  of  the  AFTO 
107  model  was  not  used  since  it  would  have  added  significantly  to  the  modeling  time  and 
the  majority  of  the  process  actions  were  highly  sequential  and  triggers  generally  provided 
sufficient  clarification  of  the  non-sequential  actions.  Finally,  a  few  resources  were 
identified  when  they  represented  a  recurring  problem  area  for  the  AFTO  107  process. 

The  decision  to  review  the  model  a  category  at  a  time  worked  very  well.  Although  the 
first  pass  through  the  model  was  rather  slow,  passes  to  review  other  categories  of 
information  went  very  quickly  since  all  participants  were  very  familiar  with  the  model. 
There  was  also  very  little  movement  between  categories  during  the  review.  For  example, 
there  were  only  a  few  times  that  the  process  description  had  to  be  reviewed  before  an 
actor  could  be  assigned.  The  majority  of  the  time,  the  process  name  provided  sufficient 
information. 

After  the  group  reached  consensus  on  the  AFTO  107  process  model,  the  process 
hierarchy  and  process  descriptions  were  copied  to  a  GroupSystems  Group  Outliner 
session.  Participants  then  used  Group  Outliner  to  identify  AFTO  107  process  problems 
and  possible  solutions  to  begin  the  process  improvement  brainstorming  process.  Finally, 
participants  completed  a  GroupSystems  Survey  to  get  their  feedback  on  the  Process 
Modeler,  the  quality  of  the  AFTO  107  process  model,  and  the  approach  used  to  develop 
the  model. 
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Outcome 


The  output  from  the  meeting  is  included  in  Appendix  A.  The  final  AFTO  107  process 
model  included  88  process  nodes.  Descriptions  were  provided  for  all  processes.  Most 
sub-process  and  action  level  processes  had  more  than  one  actor  identified  as  being 
responsible  for  accomplishing  the  process.  Multiple  actors  were  identified  when  (1) 
several  offices  played  key  roles  in  accomplishing  the  process  or,  (2)  the  responsibility  for 
a  process  varied  at  different  Air  Force  bases.  The  process  of  identifying  actors  seemed  to 
really  emphasize  this  latter  problem.  As  discussed  in  the  previous  section,  triggers  and 
resources  were  also  identified  when  appropriate. 

Developing  the  AFTO  107  process  model  also  seemed  to  emphasize  other  problems  as 
well.  During  a  short  GroupSystems  session  at  the  end  of  the  meeting,  participants  rapidly 
identified  16  problem  areas  and  recommended  possible  solutions  for  approximately  half 
the  problems.  Output  from  this  activity  is  included  in  Appendix  A. 

Results  of  the  survey  conducted  at  the  close  of  the  session  were  very  positive.  Detailed 
survey  results  are  included  in  Appendix  A  and  are  briefly  summarized  here.  The  average 
participant  assessment  of  the  AFTO  107  process  model  ranged  from  4.0  to  4.2  (1  -  poor, 

5  —  excellent)  on  all  quality  characteristics.  The  average  rating  of  the  meeting  approach 
was  even  higher  at  4.5  on  a  similar  5-point  scale.  Participants  did  suggest  that  both  the 
process  model  and  the  overall  meeting  could  have  been  improved  with  broader 
participation  by:  (1)  Air  Force  staff  and  (2)  other  Air  Force  units. 

Participants’  assessments  of  the  Process  Modeler  prototype  were  also  extremely 
encouraging.  Although  participants  strongly  emphasized  a  few  critically  needed 
improvements,  they  still  rated  this  first  version  of  the  Process  Modeler  a  4  (out  of  a 
possible  5)  on  all  functionality,  usability  and  ease  of  use  questions  except  recovering 
from  errors.  This  last  rating  was  expected  since  the  Process  Modeler  did  have  a  few 
problems  that  required  users  to  completely  exit  the  tool,  then  restart  the  browser  and 
reload  the  software  and  model  whenever  they  occurred.  Other  recommended 
improvements  included:  (1)  elimination  of  the  continual  redrawing/repositioning  of  the 
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process  tree  hierarchy  each  time  anyone  modified  it,  (2)  addition  of  common  editing 
capabilities  such  as  cut  and  paste,  and  (3)  extending  the  current  process  name  limit  from 
40  characters  to  at  least  60.  The  first  recommendation  was  implemented  prior  to  the 
second  meeting  of  the  technology  demonstration,  which  is  described  next. 

3.2.3  Phase  2:  Same  Time,  Different  Place  Meeting 

The  second  phase  of  the  DOME  Technology  Demonstration  was  a  same  time,  different 
place  meeting  held  simultaneously  at  Mountain  Home  Air  Force  Base  in  Mountain 
Home,  Idaho,  and  Robins  Air  Force  Base  in  Warner  Robins,  Georgia,  on  6  November 
1998.  The  detailed  description  of  this  meeting  follows  the  same  format  used  to  discuss 
the  first  meeting. 

Task 

The  AFTO  107  process  model  was  further  refined  during  the  second  meeting  of  the 
technology  demonstration  using  the  same  basic  approach  used  in  the  earlier  meeting.  The 
primary  task  for  this  meeting,  however,  was  to  complete  identification  of  AFTO  107 
process  problems  and  possible  solutions,  and  to  consolidate  those  solutions  into  a 
recommended  process  improvement  action  list. 

Group 

Eighteen  Air  Force  personnel  attended  the  kick-off  for  the  meeting.  However,  only 
twelve  actively  participated  throughout  the  entire  meeting  and  remained  to  complete  the 
questionnaire  at  the  end  of  the  meeting.  A  few  participants  left  early,  possibly  because  of 
the  technology  problems  that  slowed  the  start  of  the  meeting.  Other  personnel  left  during 
the  day  because  of  other  mission  requirements,  a  common  problem  when  meetings  are 
held  on-site.  The  Mountain  Home  logistician  and  engineer  who  participated  in  the  first 
meeting  were  joined  by  eleven  local  maintenance,  quality  assurance,  plans  and 
scheduling,  and  other  operational  personnel  at  the  Mountain  Home  AFB  meeting 
location.  The  F-15  maintenance  manager  from  one  Air  Force  MAJCOM  and  the  F-15 
AFTO  107  manager  and  reengineering  specialist  from  Wamer-Robins  Air  Logistics 
Center  were  joined  by  an  engineer  from  the  F-15  project  office  and  the  DOME  project 
manager  at  the  Robins  AFB  meeting  site.  New  military  and  civilian  participants 
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generally  had  less  experience  than  the  first  meeting  participants,  dropping  the  average 
total  experience  for  all  participants  to  just  under  20  years  experience  and  average  AFTO 
107  experience  to  8.5  years.  New  participants  were  not  familiar  with  the  DOME  project. 
While  most  participants  used  computers  at  least  several  times  a  day  and  had  good  to  very 
good  experience  using  an  Internet  browser,  they  all  reported  limited  or  no  GroupSystems 
or  modeling  experience. 

The  three  CMI  researchers  from  the  first  meeting  also  facilitated  and  observed  the  second 
meeting,  two  at  Mountain  Home  and  one  at  Robins  AFB. 

Context 

The  second  meeting  of  the  technology  demonstration  was  conducted  as  a  same  time, 
different  place  meeting  using  the  new  GroupSystems  meeting  facilities  set-up  at 
Mountain  Home  and  Robins  AFBs  as  part  of  the  DOME  contract.  The  meeting  was 
scheduled  for  0730  - 1230  MST  (0930  -  1430  EST)  to  accommodate  the  time  differences 
between  the  two  sites.  Technical  support  was  provided  by  a  combination  of 
communications  and  computer  Air  Force  and  contractor  base  support  personnel  at  both 
locations.  Technical  specialists  were  supposed  to  test  their  individual  components  of  the 
system  prior  to  the  meeting.  However,  as  discussed  in  the  next  section,'  many  technical 
problems  still  existed  when  CMI  researchers  arrived  two  days  before  the  meeting.  In 
addition,  access  to  the  Robins  meeting  room  was  limited  to  after  hours  because  a  non- 
DOME  meeting  was  scheduled  in  the  room  for  both  days.  This  greatly  complicated 
trouble-shooting  at  Robins  and  resulted  in  several  problems  during  the  meeting. 

For  this  meeting,  only  the  Air  Force  project  manage,  the  MAJCOM  representatives  and 
CMI  researchers  were  required  to  travel  to  attend  the  meeting.  The  elimination  of  the 
travel  requirement  significantly  increased  meeting  participation,  especially  at  Mountain 
Home  AFB. 

Technology 

The  facilitators  and  all  meeting  participants  at  both  sites  used  personal  computers 
connected  to  a  local  area  network  (LAN),  and  through  the  LAN,  to  the  Internet. 
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Projectors  were  connected  to  the  facilitator’s  workstations  to  provide  a  public  display. 
The  primary  software  used  during  this  meeting  was  the  Process  Modeler  prototype. 
CMI’s  Process  Modeler  server  was  used  again,  communicating  with  the  remote  meeting 
locations  via  the  Internet.  CMI  researchers  had  to  download  and  install  Microsoft’s 
Internet  Explorer  on  all  workstations  prior  to  the  meeting  to  support  the  Process  Modeler 
clients. 

GroupSystems  software  was  also  used  during  the  meeting.  Local  participants  used  Citrix 
clients  to  connect  via  the  Internet  to  CMI’s  GroupSystems  Citrix  server  that  was  used  to 
support  the  meeting.  CMI  researchers  also  had  to  download  and  install  the  Citrix  client 
software  on  all  participants’  workstations  prior  to  the  meeting.  Extensive  testing  and 
coordination  with  technical  support  personnel  was  required  at  Mountain  Home  to 
establish  a  working  Internet  connection  for  the  meeting  room  and  to  allow  access  to 
CMI’s  servers  through  the  local  firewall.  In  addition,  Process  Modeler  testing  between 
the  University  of  Arizona,  Mountain  Home,  and  Robins  AFB  indicated  that  Robins’  poor 
Internet  connectivity  (frequent  time-outs)  caused  unexpected  missing  process  model  data 
for  some  Robins  participants. 

Video  teleconferencing  (VTC)  equipment  was  provided  to  both  sites,  also  as  part  of  the 
DOME  contract,  specifically  to  support  distributed  meetings  such  as  the  one  planned  for 
the  technology  demonstration.  Mountain  Home  and  Robins  AFBs  were  responsible  for 
providing  the  ISDN  telephone  lines  required  to  operate  the  VTC  equipment.  CMI 
researchers  arrived  to  find  ISDN  problems  at  both  locations,  indicating  that  the  VTC 
equipment  had  not  been  tested  as  promised.  Long  hours  of  coordination  with  local 
communication  personnel  and  the  VTC  vendor  were  required  to  get  the  VTC  equipment 
operational.  However,  problems  continued  to  plague  the  Robins  location  throughout  the 
meeting,  essentially  making  the  VTC  equipment  more  of  a  distraction  than  a  help.  The 
back-up  audio-conferencing  capability  was  also  extremely  limited  due  to  low  quality 
speaker-phones  at  both  meeting  locations. 
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Process 


The  meeting  began  with  a  welcome  from  the  CMI  researchers  at  Mountain  Home, 
followed  by  a  brief  presentation  by  the  CMI  researcher  at  Robins  on  the  goals  of  the 
DOME  technology  demonstration,  specific  meeting  goals  and  general  meeting 
guidelines.  Because  of  lack  of  presentation  software  on  Mountain  Home  participant’s 
computers,  this  presentation  could  not  be  displayed  on  participants’  workstations  and  had 
to  be  displayed  using  the  CMI  researcher’s  laptop  connected  to  the  projector.  The  plan 
was  then  to  have  all  meeting  participants  introduce  themselves  using  VTC,  but  VTC 
problems  made  this  impossible.  Participants  did  sign-in  using  GroupSystems  Topic 
Commenter. 

The  Process  Modeler  prototype  was  introduced  next  using  the  same  training  procedure 
and  “Go  TDY”  model  used  in  the  first  meeting.  All  participants  at  both  locations  then 
had  the  opportunity  to  practice  adding  and  modifying  information  in  the  model. 

CMI  researchers  at  Mountain  Home  then  facilitated  a  chauffeured  review  of  the  AFTO 
107  process  model  developed  during  the  first  technology  demonstration  meeting.  The 
purpose  of  this  review  was  to:  (1)  familiarize  new  participants  with  the  model,  (2)  have 
all  participants  recommend  improvements  and  changes  to  the  model,  and  (3)  achieve 
group  consensus  on  model  content.  Initially,  all  participants  reviewed  the  model  on  their 
personal  workstations  with  changes  made  by  both  the  facilitator  and  participants. 
However,  part  way  through  the  review.  Mountain  Home  AFB  lost  Internet  connectivity 
for  the  entire  base  for  over  an  hour.  CMI  researchers  quickly  dialed  into  the  CMI  Process 
Modeler  server  using  a  personal  laptop  and  connected  the  laptop  to  a  projector  so  that 
Mountain  Home  participants  could  follow  the  review  using  the  public  screen.  Robins 
AFB  participants  maintained  their  Internet  connection,  so  they  could  continue  to  review 
the  model  at  their  personal  workstations  or  at  their  neighbor's  workstation  when  poor 
connectivity  caused  data  loss  at  their  workstation.  Throughout  the  review,  the  two 
meeting  locations  were  connected  via  audio  conferencing  so  that  the  participants  from 
Robins  could  hear  the  facilitator's  comments  and  ask  questions/make  comments  as 
desired.  Both  locations  had  a  very  difficult  time  following  group  discussions  at  the  other 
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site.  In  addition,  Robins  participants  requested  clarification  of  what  process  node  was 
currently  being  reviewed,  since  they  had  no  way  of  viewing  what  node  the  facilitator  was 
highlighting.  The  entire  review  was  extremely  time  consuming  because  of  the 
technology  problems,  poor  inter-site  communication,  and  the  length  of  the  model.  Some 
participants  seemed  to  lose  interest,  buy  many  important  improvements  were  made  to  the 
model  during  the  review. 

Following  the  chauffeured  review,  participants  were  asked  to  work  in  parallel  to  identify 
AFTO  107  process  problems  and  recommend  improvements.  A  new  process  information 
panel  was  added  by  the  facilitator  to  the  Process  Modeler  to  specifically  capture  these 
problems  and  solutions.  Problems  and  solutions  identified  during  the  first  meeting  were 
copied  onto  these  panels  for  the  appropriate  process  prior  to  the  meeting.  After 
participants  completed  their  input,  one  CMI  researcher  at  Mountain  Home  led  both  sites 
through  a  chauffeured  review  of  the  problems  and  solutions.  Participants  discussed  and 
clarified  solutions  and  then  recommend  specific  process  improvement  action  items 
needed  to  start  implementation/evaluation  of  those  solutions.  A  second  CMI  researcher 
at  Mountain  Home  recommended  these  action  items  in  a  GroupSystems  Categorizer 
session. 

The  meeting  concluded  with  an  overview  of  plans  for  the  next  meeting,  a  short  training 
session  on  the  GroupSystems  tools  that  would  be  used  in  that  meeting.  Finally,  the 
twelve  remaining  participants  used  GroupSystems  Survey  to  complete  a  questionnaire 
similar  to  the  one  used  in  the  first  meeting. 

Outcome 

Output  from  the  second  meeting  is  included  in  Appendix  B.  The  final  AFTO  107  process 
model  increased  from  88  to  93  process  nodes.  Descriptions,  actors,  triggers,  and 
resources  were  added  or  modified  when  required.  Approximately  40  problems  and  40 
proposed  solutions  were  also  documented  as  part  of  the  process  model,  up  from  the  16 
problems  and  8  solutions  identified  during  the  first  meeting.  The  40  proposed  solutions 
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were  combined  into  9  recommended  process  improvement  action  items  that  were 
documented  using  GroupSystems.  Output  from  this  activity  is  included  in  Appendix  B. 

Results  of  the  survey  conducted  at  the  close  of  the  session  were  again  very  positive. 
Detailed  survey  results  are  included  in  Appendix  B  and  are  briefly  summarized  here.  The 
average  participant  assessment  of  the  AFTO  107  process  model  ranged  from  4.2  to  4.5 
(up  from  4.0  -  4.2)  on  all  quality  characteristics.  Quality  of  the  recommend 
improvements  averaged  4.2.  The  average  rating  of  the  overall  meeting  approach  did  drop 
slightly  from  4.5  to  4.3,  but  participants  rating  of  the  distributed  aspects  of  the  meeting 
averaged  an  extremely  high  4.5  to  5.0.  Participants  did  indicate  some  difficult  in  working 
with  participants  at  the  other  meeting  location,  rating  this  item  3.5,  a  full  point  lower  than 
the  4.5  rating  for  working  with  participants  at  their  location. 

Process  Modeler  problems  with  the  constant  redrawing/repositioning  of  the  process 
hierarchy  identified  during  the  first  meeting  were  resolved  prior  to  the  second  meeting. 
This  change,  possibly  combined  with  some  participant’s  familiarity  with  the  tool,  resulted 
in  participant’s  assessment  of  the  Process  Modeler  prototype’s  ease  of  use  increasing 
from  4.1  to  4.3.  The  major  problem  identified  during  this  meeting  was  the  missing  data 
caused  by  Robins’  poor  Internet  connectivity.  Some  participants  also  provided  some 
interesting  recommendations  for  improvement,  but  in  general,  all  participants  were 
remarkably  positive  about  the  prototype. 

3.2.4  Phase  3:  Different  Time,  Different  Place  Meeting 

The  third  and  final  phase  of  the  DOME  Technology  Demonstration  was  a  different  time, 
different  place  meeting  held  from  11-27  January  1999  with  wing,  MAJCOM,  and  depot 
personnel  participating  directly  from  their  offices  at  their  convenience  during  that  time- 
frame.  The  following  detailed  description  of  this  meeting  uses  the  same  format  as  the 
first  two  meeting  descriptions. 
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Task 


During  the  final  meeting,  participants  were  asked  to  comment  on  the  recommended 
AFTO  107  process  improvement  action  list  developed  during  the  second  meeting,  and 
then  to  vote  on  the  importance  and  feasibility  of  each  of  the  recommended  action  items. 

Group 

All  participants  from  the  first  two  technology  demonstration  meetings  were  invited  to 
participate  in  the  final  meeting. 

Context 

The  final  meeting  of  the  technology  demonstration  was  conducted  as  a  different  time, 
different  place  meeting  with  participants  using  their  personal  computers  to  participate 
directly  from  their  desktops  at  their  convenience.  CMI  researchers  set-up  and  monitored 
the  meeting  from  the  University  of  Arizona.  No  facilitators  or  Air  Force  personnel  were 
required  to  travel  to  participate  in  this  fully  distributed  meeting.  The  lack  of  travel  should 
have  significantly  increased  participation,  however,  the  lack  of  motivation  to  participate 
during  an  established  time  frame  seemed  to  be  a  stronger  factor  and  negatively  impacted 
meeting  participation. 

Technology 

The  primary  software  used  during  this  meeting  was  GroupSystems.  Local  participants 
used  Citrix  client  software  to  connect  via  the  Internet  to  CMI’s  GroupSystems  Citrix 
server.  CMI  researchers  had  installed  the  necessary  Citrix  software  on  the  personal 
computers  of  WR-ALC  participants.  Mountain  Home  participants  had  to  install  this 
software  on  their  own  computers  by  downloading  it  from  Mountain  Home’s  intranet  site. 
Other  participants  had  to  download  the  software  (for  free)  from  the  vendor.  All 
participants  used  an  Internet  browser  (which  they  may  also  have  had  to  install)  to  access 
CMI’s  DOME  Citrix  web  site  to  login  to  the  GroupSystems  session.  Complete 
instructions  were  provided  to  all  participants  via  Email,  with  follow-up  support  provided 
by  CMI  researchers  by  phone  and  Email.  Although  some  participants  had  questions, 
everyone  who  requested  assistance  was  eventually  able  to  login  to  the  GroupSystems 
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session.  Instructions  were  also  provided  on  how  to  access  Process  Modeler  to  view  the 
final  AFTO  107  process  model,  but  no  participants  seemed  to  use  this  capability. 

Process 

During  the  first  week  of  the  meeting,  participants  were  asked  to  login  to  GroupSystems  to 
review  and  comment  on  the  action  items  developed  during  the  previous  meeting. 
Instructions  for  adding  new  items  and  comments  were  provided  via  Email.  At  the 
beginning  of  the  second  week,  CMI  researchers  shifted  the  10  action  items  to  two  votes: 
(1)  the  importance  of  each  action  item  for  improving  the  AFTO  107  process  and  (2)  the 
feasibility  of  each  action  item  being  implemented  by  Air  Force.  Again,  complete 
instructions  were  provided  by  Email.  Participants  had  just  over  one  week  to  login  to 
GroupSystems  and  record  their  votes. 

CMI  researchers  monitored  participation  throughout  the  entire  two  and  a  half  week 
meeting,  sending  Emails  encouraging  participation  and  offering  assistance  mid-way 
through  each  week  with  status  messages  provided  at  the  end  of  each  week.  Both 
activities  were  extended  because  of  low  participation,  but  this  had  only  a  limited  impact 
on  the  vote  and  no  apparent  impact  on  the  initial  comment  activity. 

Outcome 

Participation  during  this  final  meeting  was  very  disappointing.  During  the  review  of  the 
recommended  AFTO  107  process  improvement  action  list,  only  one  new  action  and  one 
comment  were  added  by  participants  (see  Appendix  C).  Seven  participants  did  vote  on 
the  importance  of  these  action  items,  with  five  of  those  also  voting  on  their  feasibility. 
The  voting  results  show  some  interesting  similarities  and  differences  between  the 
importance  and  feasibility  of  the  recommended  action  items.  For  example,  both  votes 
rated  establishing  and  standardizing  on  a  single  central  107  POC  as  the  top  two  items.  In 
contrast.  Air  Staff  funding  of  a  real-time  system  was  rated  as  the  third  most  important, 
but  the  least  feasible  improvement  action.  Detailed  voting  results  are  included  in 
Appendix  C. 
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3.3  Cost-Benefit  Analysis 

There  were  many  tangible  and  intangible  benefits  of  using  the  DOME  methodology  to 
improve  the  AFTO  107  process,  especially  in  a  distributed  environment.  Some  of  these 
benefits,  such  as  the  improved  quality  of  the  AFTO  107  process  model  and  recommended 
improvements,  have  already  been  mentioned  in  the  previous  sections. 

An  additional  tangible  benefit  of  the  DOME  approach  is  the  significant  man-hour  and 
cost  savings  for  Air  Force  representatives  who  did  not  need  to  travel  to  participate  in 
these  meetings.  An  estimate  of  these  savings  for  the  two  distributed  technology 
demonstration  meetings  is  shown  in  Table  3.  Estimates  are  based  on  the  assumption  that 


Description 

Meeting  2 

Meeting  3 
(Invited) 

Meeting  3 
(Actual) 

Total  Air  Force  Representatives 

17 

18 

7 

-  #  Representatives  traveling  to 
meeting 

2 

0 

0 

#  Representatives  participating 
without  travel 

15 

18 

7 

Estimated  meeting  plus  travel  time 

3  days 

2  days 

2  days 

Average  per  person  travel  costs 

$810 

$690 

$690 

Total  travel  cost  avoidance 

$12,150 

$12,420 

$4,830 

Per  person  lost  productivity  due  to 
travel 

16  hours 

12  hours 

12  hours 

Total  lost  productivity 

240  hours 

216  hours 

84  hours 

Table  3.  Travel  Costs 


Air  Force  representatives  would  have  traveled  to  the  University  of  Arizona's  meeting 
facilities  if  the  Mountain  Home  and  Robins  meeting  rooms  had  not  been  built  as  part  of 
the  DOME  contract.  Since  meeting  two  was  a  full-day  meeting,  it  was  assumed  that 
participants  would  require  approximately  one  day  for  travel  to  the  meeting  and  a  second 
day  to  return  home.  Meeting  three  could  have  been  accomplished  in  a  few  hours  during  a 
face-to-face  meeting,  so  it  was  assumed  that  participants  could  have  returned  home  later 
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that  same  day.  Travel  costs  were  estimated  based  on  an  average  $500  for  airfare,  $85 
hotel  plus  $38  per  day  for  per  diem  (Tucson  1998  rates),  and  $45  per  day  for  rental  car 
(one  car  for  each  three  travelers). 

Total  cost  avoidance  for  just  the  two  distributed  technology  demonstration  meetings  was 
approximately  $24,570  and  456  man-hours.  In  addition,  in  a  face-to-face  environment, 
all  attendees  of  meeting  3  would  have  fully  participated  in  the  meeting  activities.  Even 
when  conservatively  considering  only  those  Air  Force  representatives  who  participated  in 
the  final  meeting,  the  cost  avoidance  was  $17,250  and  324  man-hours. 
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4.0  CONCLUSION 


4.1  Summarization  of  Results  and  Lessons  Learned 
Strategic  Planning 

DOME  support  can  improve  the  strategic  planning  processes  of  the  Air  Force.  DOME- 
supported  strategic  planning  allowed  a  Wing  of  several  thousand  people  to  meet  and 
develop  a  holistic  strategic  plan  in  less  than  three  months,  and  allowed  each  level  of  the 
Wing  to  build  on  the  previous  level’s  ideas  and  comments.  DOME  allowed  hundreds  of 
people  to  be  directly  involved  the  strategic  planning  process.  Involving  large  numbers  of 
personnel  in  the  planning  process  helps  produce  a  high  quality  product  that  could  not  be 
developed  practically  using  traditional  face-to-face  methodology.  The  result  was  higher 
quality  strategic  plans  developed  in  less  time  than  traditional  strategic  planning  methods. 

Distributed  Facilitation 

Asynchronous  sessions  are  defined  as  those  in  which  the  users  participate  in  different 
time/different  place  mode.  Several  early  asynchronous  GSS  sessions  had  difficulties  for 
a  number  of  reasons.  One  real  “show  stopper ”  was  when  people  did  not  participate  at  all 
when  they  logged  in  or  they  failed  to  log  into  the  system  at  all.  Interviews  and 
observations  suggest  that  people  experience  high  ambiguity  working  asynchronously. 
They  lack  the  cues  available  in  synchronous  interactions  that  help  them  to  eliminate 
uncertainty  and  ambiguity.  Without  cues  and  direct  immediate  communication  through 
which  to  ask  questions  for  clarification,  participants  struggle  to  understand  the  meaning 
of  facilitator  instructions,  shared  objects,  and  the  contributions  of  others.  Minimal  or  no 
feedback  makes  participants  feel  alone  and  may  cause  them  to  question  whether  their 
efforts  are  warranted  or  will  even  be  noticed.  They  aren’t  sure  who  will  see  their  work, 
or  how  it  might  be  interpreted.  They  therefore  chose  not  to  participate. 

In  order  to  overcome  the  problems  encountered  in  sessions,  we  developed  a  distributed 
facilitation  process  that  consisting  of  eight  (8)  rules-of-thumb  to  serve  as  a  set  of  steps  the 
facilitator  can  follow  to  engage  participants  and  keep  then  involved  in  the  process.  Each 
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rule-of-thumb  is  described  below.  These  eight  (8)  rules-of-thumb  resulted  mainly  from 
experiences  using  the  software  in  face-to-face  and  distributed  settings.  These  techniques 
may  help  facilitators  initiate  and  sustain  successful  asynchronous  interactions. 

Distributed  Facilitation  Process  Rules-of-Thumb 

1 .  Select  a  task(s)  in  which  participants  have  high  vested  interests. 

Participants  were  mostly  middle  and  senior-level  managers  with  multiple 
responsibilities  competing  for  their  attention.  Asynchronous  sessions  are  more 
difficult  and  require  more  attention  resources  than  synchronous  ones.  As  a  result, 
if  participants  don’t  have  high  vested  interest  in  the  goals  or  outcomes  of  an 
asynchronous  session,  other  demands  will  consume  their  attention.  Without  pre¬ 
specified  times  and  places  for  attendance,  sessions  cannot  not  compete  for  the 
users’  attention.  However,  if  participants  have  a  high  stake  in  the  goals  and 
outcomes,  this  may  enable  them  to  focus  enough  attention  to  keep  the  process 
moving. 

2.  Establish  a  champion  with  clout  and  vested  interest. 

This  is  one  way  to  create  vested  interest  in  participation.  As  one  highly-placed 
leader  said,  “ The  rule  here  is,  if  my  boss  is  interested,  I’m  excited.”  Thus  it  is 
useful  if  “ someone  at  the  top ”  thinks  the  session  is  important  and  lack  of 
participation  may  be  noticed  in  a  negative  light,  whereas  meaningful  participation 
may  also  be  noticed  in  a  positive  light. 

3.  Explicitly  verify  the  task  cannot  be  accomplished  more  easily  by  another  method. 

Group  members  that  thought  there  was  an  easier  way  to  accomplish  the  task 
typically  never  participated  in  asynchronous  sessions.  The  team  leader  and 
facilitator  must  ask  each  participant  well  before  the  session,  “ Can  you  think  of  an 
easier  way  we  can  do  this?”  It  was  important  that  participants  explicitly  notice 
for  themselves  that  an  asynchronous  session  was  the  easiest  way  to  accomplish 
the  team  goals. 

4.  Facilitator  must  directly  contact  all  participants  to  confirm  commitment  to  participate. 

Because  asynchronous  sessions  are  harder  to  execute  and  easier  to  ignore  than 
synchronous  ones,  facilitators  need  to  pick  up  the  phone  and  speak  directly  to 
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every  participant  and  get  specific  commitments  to  participate.  Further,  facilitators 
need  to  walk  each  group  member  on  a  torn:  of  a  well  prepared  virtual  collaboration 
space  before  work  begins  and  explain  the  task,  the  process,  the  collaborative 
objects,  and  answer  any  questions  the  group  member  asks. 

5.  Each  distributed  project  should  kick-off  with  a  same-time-different-place  voice-and- 
DOME  on-line  activity. 

The  kick-off  event  allows  participants  to  become  familiar  with  the  virtual 
collaboration  space,  with  the  process  it  is  to  support  and  with  the  other  team 
members.  It  eliminates  excuses  about  technical  failures  preventing  participation. 
Questions  such  as  the  following  are  answered:  How  is  the  collaborative  space 
organized?  What  is  the  purpose/meaning  of  each  activity?  Where  should 
comments  and  contributions  be  submitted  and  at  what  level  of  detail?  How  do 
you  move  around  the  space  and  use  the  tools  to  participate?  The  synchronous 
kickoff  event  reduced  ambiguity  and  uncertainty,  and  improved  participation  later 
on  in  session. 

6.  Two  deliverables  of  the  Kick-off  session  should  be  (A)  an  explicit  prioritized  set  of 
action  items  for  asynchronous  participation  and  (B)  a  firm  schedule  for  the  next 
synchronous  interaction. 

Each  action  item  must  be  very  detailed  and  include  an  action,  an  actor,  a  deadline, 
a  deliverable,  and  a  method  to  measure  the  quality  of  the  work.  Making  users 
aware  of  expectations,  and  the  date  for  the  next  synchronous  activity,  creates  a 
sense  of  accountability  and  helps  them  to  commit  to  the  project. 

7.  Participant  instructions  must  be  vastly  more  explicit  than  would  be  necessary  for 
synchronous  sessions. 

If  there  is  any  way  for  participants  to  misunderstand  written  instructions  they  will 
do  so.  In  asynchronous  sessions  teams  or  members  may  drift  a  long  way  into 
unproductive  processes  before  facilitators  identify  and  address  problems.  Once 
identified,  it  is  difficult  to  signal  the  team  that  a  shift  of  direction  is  needed.  In 
synchronous  sessions  such  changes  of  direction  are  implemented  with  a  few 
words  from  the  facilitator  and  a  few  questions  from  the  group  members.  In 
asynchronous  sessions,  such  interactions  may  last  over  a  day  or  longer,  depending 
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on  how  often  the  facilitator  and  participants  log  into  the  session.  Therefore, 
asynchronous  distributed  sessions  require  a  very,  very  explicit  set  of  participant 
instructions,  which  should  have  been  pilot,  tested  with  several  people  to  eliminate 
ambiguity.  The  instructions  must  be  complete,  unambiguous,  specific,  detailed, 
and  easily  understandable  by  all  participants.  No  small  order. 

8.  Every  DOME  Session  should  include  a  separate  process  channel  monitored  by  the 
facilitator. 

In  synchronous  DOME  sessions,  participants  simply  ask  the  facilitator  questions 
to  clarify  process  issues.  In  asynchronous  distributed  sessions  both  oral 
communication  and  sometimes  even  direct  immediate  feedback  are  precluded. 
Therefore,  it  is  valuable  to  provide  a  “back  channeF  for  discussing  session, 
process  and  other  non-task  related  information.  Persistent  chat  windows  proved 
effective  for  this  purpose.  In  some  cases  e-mail  also  provide  adequate  support. 
Several  of  the  sessions  simply  built  in  an  extra  topic  for  comments  about  the 
process  and  the  facilitator  monitored  it  regularly. 

AI  Facilitation 

Tools  have  been  built  and  tested  that  help  with  the  visualization  of  group  memory.  There 
is  a  need  to  maintain  organizational  memory,  and  these  tools  help  to  manage  the 
knowledge  for  that  purpose.  The  text  from  group  sessions  is  sorted,  categorized,  and 
mapped  into  relevant  topics.  The  AI  tools  created  for  preprocessing  do  a  simple  form  of 
machine  learning  called  statistical  learning,  specifically  multidimensional  scaling.  The 
advantage  is  that  it  remains  immune  to  prejudices  of  the  researcher  in  finding  patterns.  It 
does  so  by  translating  the  dissimilarities  into  distances  on  a  map.  The  disadvantage  is 
that  the  patterns  found  may  have  no  semantic  content.  Testing  of  these  tools  sought  to 
verify  that  users  would  prefer  one  type  of  preprocessing.  Results  contradicted  this, 
however,  when  it  was  found  that  multiple  views  were  preferred. 

Process  Modeling 

A  process  model  represents  a  process  and  its  related  components  in  a  time-dependent 
fashion.  A  process  model  also  captures  the  decision  logic  that  exists  within  the  process. 
Thus,  it  represents  which  events  occur  in  sequence  and  which  events  occur  in  parallel. 
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The  time  and  resources  associated  both  with  events  and  chains  of  events  may  be 
captured.  Process  models  may  be  used  to  document,  analyze,  and  improve  business 
processes.  They  are  excellent  for  supporting  analysis  of  how  to  reduce  process  and 
project  cycle  times.  Process  models  support  the  design  and  evaluation  of  new  processes 
before  embarking  on  potentially  expensive  business  or  information  system  changes. 
Process  visualization  and  analysis  are  greatly  enhanced  by  process  models.  The  ability  to 
see  where  bottlenecks  occur  and  how  events  are  sequenced  helps  a  team  see  what 
changes  may  simplify,  shorten,  and  streamline  a  process.  When  appropriate,  process 
models  may  also  be  used  to  support  capture  of  the  information  necessary  to  construct 
simulation  models.  Simulation  is  especially  helpful  when  process  bottlenecks  are  not 
easy  to  diagnose  or  visualize.  This  often  occurs  when  many  constraints  within  a  process 
impact  throughput  and  productivity. 

Although  participation  during  modeling  and  analysis  is  important,  the  current 
commercially  available  modeling  support  tools  were  single-user  tools.  Moreover,  these 
tools  were  designed  for  use  by  analysts  rather  than  to  support  non-expert  participants. 
Because  a  single  user  entered  all  input,  these  tools  limited  direct  participation  by 
stakeholders  during  what  should  have  been  a  collaborative,  team-based  effort.  Thus, 

CMI  researchers  designed  and  built  a  tool  that  did  not  have  these  restrictions,  and 
provided  support  for  multiple  users. 

Collaborative  support  is  important  for  groups  at  the  same  location,  but  CMI  researchers 
recognized  that  it  would  be  beneficial  if  a  tool  existed  to  allow  users  in  different  locations 
to  participate.  In  this  way  multiple  users  or  subgroups  can  do  some  process  mapping  and 
review  from  remote  locations.  This  allows  remote  access  events  to  be  interleaved  with 
face-to-face  meetings,  thus  reducing  the  amount  of  travel  time  and  cost  during  process 
mapping  and  analysis.  Work  on  the  DOME  research  included  building  such  a  tool:  the 
Process  Modeler. 
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All  DOME  project  and  research  goals  for  the  Process  Modeler  were  met,  as  clearly 
shown  by  its  successful  support  of  the  technology  demonstration.  Some  of  the  primary 
lessons  learned  from  the  demonstration  include  the  following: 

•  A  simple,  easy-to-use  interface  is  critical  for  the  Process  Modeler.  Users  were 
easily  able  to  add  comments  to  the  free-form  text  panels  (e.g.,  the  description 
panel),  but  had  more  difficulty  with  the  structured  actor  panel.  The  actor  panel 
interface  needs  to  be  simplified. 

•  As  the  size  of  the  Process  Model  increased,  synchronous  review  of  all  model 
information  with  the  entire  group  became  problematic.  For  example,  during  the 
second  meeting,  some  participants  lost  interest  during  the  almost  two-hour 
facilitated  review  and  improvement  of  the  model.  Possible  methods  for  avoiding 
this  problem: 

•  The  facilitator  could  review  the  model  at  a  high-level  only,  and  then  have 
participants  review  and  improve  the  model  in  parallel.  Alternatively,  if 
participants  are  familiar  with  Process  Modeler,  they  should  be  asked  to  review  the 
model  before  the  meeting. 

•  During  the  review,  some  time  was  wasted  reviewing  items  everyone  agreed  on. 
The  review  would  have  been  much  faster  if  the  group  could  have  focused 
discussion  only  on  those  processes  or  information  panels  about  which  the  group 
had  questions  or  with  which  participants  disagreed.  Process  Modeler  needs  a  way 
for  participants  to  “mark”  processes/comments  to  indicate  their  agreement  or 
disagreement.  This  capability  would  allow  participants  to  review  the  model  in 
detail  individually,  either  synchronously  or  asynchronously.  The  entire  group 
could  then  quickly  complete  the  review  together  by  simply  reviewing  those  areas 
“marked”  by  participants. 

•  In  general,  as  the  size  of  the  group  increases,  the  meeting  will  be  more  effective  if 
more  time  is  spent  with  participants  working  in  parallel  with  less  time  spent  on 
facilitated  reviews  and  discussions. 
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•  The  use  of  video  teleconferencing  (VTC)  would  have  been  a  valuable  addition  to 
the  same  time,  different  place  meeting.  As  a  minimum,  starting  the  meeting  with 
introductions  where  everyone  could  see  participants  at  the  other  site  would  have 
improved  inter-site  communication  between  all  participants.  Because  the  VTC 
was  not  working,  communication  was  limited  to  audio-conferencing,  primarily 
between  the  facilitator  and  each  site’s  participants  versus  directly  between 
participants. 

•  Back-up  capabilities  are  essential  for  all  technology  critical  to  meeting  success. 
For  example,  during  the  second  meeting,  audio-conferencing  was  used  when  VTC 
failed  and  dial-up  communications  were  used  when  Mountain  Home’s  Internet 
connection  went  down.  If  these  back-ups  had  not  been  available,  the  distributed 
meeting  would  have  been  cancelled. 

•  Participation  in  the  different  time,  different  place  meeting  was  disappointing. 

This  may  have  been  caused  by  the  delay  between  the  second  and  third  meetings  or 
by  lack  of  incentives  for  participation.  Motivation  would  have  been  higher  if  it 
had  immediately  followed  the  second  meeting  or  if  participants  knew  that  their 
input  was  critical  for  a  scheduled  follow-on  meeting. 

Opportunities  for  Use  of  Tools  and  Methodologies  by  Other  AF  Users 

The  DOME  system  has  been  installed  and  transitioned  to  MH  AFB  and  WR  AFB. 
However,  the  DOME  tools  and  methodologies  have  great  potential  for  use  by  many  other 
organizations  throughout  the  Air  Force.  DOME’S  collaborative  meeting  technology,  for 
example,  can  be  utilized  by  virtually  any  organization  that  regularly  holds  meetings.  One 
organization  at  Robins  AFB,  the  Procurement  and  Acquisitions  Office  (PK),  is  already 
using  the  tool  (the  DOME  installation  in  the  Robins  RE  office)  for  developing  risk 
assessments  of  potential  projects.  They  have  found  the  tool  so  valuable  and  use  it  so 
often  that  they  are  considering  building  their  own  collaborative  meeting  room. 
Additionally,  the  Air  Force  Battle  Lab  at  Mountain  Home  AFB  has  also  expressed 
interest  in  using  DOME  in  their  work.  The  ActionPlanner  and  SenseMaker  templates 
developed  for  DOME  will  be  a  tremendous  aid  to  organizations  unfamiliar  with 
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conducting  collaborative  meetings.  These  templates  provide  very  specific  guidelines  for 
using  DOME  for  strategic  planning  type  meetings. 

The  DOME  collaborative  process-modeling  (PM)  tool  also  has  many  potential  uses 
throughout  the  Air  Force.  The  PM  tool  can  be  used  for  modeling  virtually  any  business 
process  and  the  resulting  model  can  be  used  for  many  purposes  such  as  functional  process 
improvement  or  training.  The  distributed  capabilities  of  the  tool  make  it  ideal  for 
modeling  business  processes  that  exist  in  many  different  locations. 


4.2  Future  Research 


Distributed  Tools 

The  DOME  project  and  technology  demonstration  results  highlighted  several  areas  for 
future  research  and  enhancement  of  distributed  tools  for  process  analysis  and 
improvement.  Proposed  Process  Modeler  enhancements  include: 

•  Improve  tool  reliability  and  communication  robustness  for  poor  direct  or  slow 
dial-up  Internet  connections. 

•  Enhance  graphical  process  modeling  component  by  simplifying  the  user  interface, 
improving  automatic  layout  of  processes  and  links,  and  providing  a  capability  to 
print  graphical  models. 

•  Add  an  import/export  capability  with  GroupSystems  and  other  modeling  tools. 

•  Improve  metrics  component  by  analyzing  which  metrics  to  capture,  developing 
panels  to  capture  identified  metrics,  and  exploring  feasibility  of  export  to 
simulation  tools. 

•  Add  new  features  to  support  distributed  facilitation  such  as  match  views, 
participation  monitoring  and  consensus  polling. 

•  Easily  used  in  a  distributed  same-time/  different-place  or  different-time/different- 
place  setting 

•  Textual  component  used  successfully  in  DOME  technology  demonstration 
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•  Graphical  component  used  very  little;  functional,  but  needs  refinement 

The  success  of  the  Process  Modeler  during  the  technology  demonstration  proved  the 
feasibility  of  this  concept  and  opens  the  door  for  research  into  other  collaborative  Java- 
based  tools.  For  example,  a  simplified  collaborative  writing  tool  specifically  designed  to 
work  over  the  Internet  would  allow  simple  administration  and  writing  of  a  wide-variety 
of  documents  by  distributed  and/or  asynchronous  participants.  The  objective  of  research 
on  a  Java  GroupWriter  would  be  to  develop  user  requirements  and  a  prototype  of  a  tool 
for  collaborative  writing  of  multi-author  documents  (e.g.,  policy  documents)  in  the  Java 
programming  language.  Potential  benefits  of  preparing  a  collaborative  document  using 
Java  GroupWriter  include:  (1)  increased  information  sharing,  (2)  decreased  turnaround 
time,  and  (3)  increased  interest  and  contributions.  In  addition,  the  wider  participation  of 
collaborative  writing  process  should  improve  document  quality  and  increase  user  buy-in. 

Facilitation 

This  research  extends  the  knowledge  about  distributed  DOME  facilitation,  participation, 
and  leadership  by  involving  users  in  the  field.  Observations  of  these  sessions  by 
researchers,  facilitators,  team  leaders,  and  participants  reveal  new  insights  and  lead  to  the 
development  of  a  Distributed  Facilitation  Process  that  is  tested  in  the  field  and 
demonstrated  to  greatly  improve  both  processes  and  outcomes.  This  process  provides  a 
foundation  from  which  to  continue  research  to  discover  the  underlying  mechanisms  that 
cause  the  steps  in  the  process  to  be  effective.  Following  are  some  additional  distributed 
facilitation  technical  challenges  that  researchers  and  developers  will  have  to  address. 

•  Additional  mechanisms  for  tracking  data  links  help  facilitators 
maintain  awareness  of  participants  with  data  links  but  without  audio 
links. 

•  There  is  a  strong  need  to  integrate  the  audio  and  data  links  in  such  a 
way  that  the  facilitator  can  track  which  participants  are  connected  via 
audio  and/or  data. 
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•  Protocols  for  voice  and  data  communications  help  to  eliminate 
confusion  and  orientation  time  at  session  initiation  and  when 
participants  exit  a  session. 

Future  research  should  include  doing  additional  field  sessions,  as  well  as  both  theory 
development  and  experimental  verification  to  gain  an  understanding  of  the  underlying 
constructs  and  their  affects  on  collaborative  productivity  for  distributed  teams. 
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Session  Name: 
Report  Generated  : 


Meeting  1  Output 

Process  Modeler  Report 

Process  AFTO  107  Requests  for  Tech  Asst 
10/21/98,  9:45:30  AM 

Process  Tree  Hierarchy 


Process  AFTO  107  Requests  for  Tech  Assist 

•  Determine  Repair  Needs 

•  Research  Repair  Requirements 

•  Research  Repair  in  Technical  Orders 

•  Review  Other  Related  Manuals 

•  Contact  Other  Bases  for  Similar  Problems 

•  Review  Maintenance  History 

•  Determine  if  Capability  is  at  Base  Level 

•  Contact  Depot  for  Special  Assistance 

•  Determine  Parts  Availability 

•  Determine  Equipment  Availability 

•  Repair  Locally/Retum  to  Operation 

•  Prepare  &  Submit  107  Request 

•  Produce  107  Narr  at  Work  Center  Level 

•  Describe  Problem 

•  Create  Drawings  &  Other  Items  Req  by  Depot 

•  Prepare  Specific  Depot  Repair  Request 

•  Review  107  Narrative 

•  Review  Narrative  for  Completeness 

•  Validate  Local  Resources 

•  Determine  Fleet  Implications 

•  Initiate  107  Checklist 

•  Complete  107  &  Submit  Req  for  Assistance 

•  Review  1 07  Narr/Checklist  Completeness 

•  Prepare  107  for  Transmission 

•  Submit  107  to  MAJCOM/Depot 

•  Verify  with  MAJCOM/Depot  Receipt  of  1 07 

•  Change  Aircraft/Equipment  Possession 

•  Process  107  Request  at  MAJCOM 

•  Receive  107  at  MAJCOM 

•  Evaluate  107  Request 

•  Validate  107 

•  Research  107 
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•  Request  Additional  Information  from  Unit 

•  Certify  funding  is  available  for  repair 

•  Cost  estimate  pre-certification 

•  Review  Cost  Prohibitive  Estimates 

•  Execute  107  Disposition 

•  Forward  107  Certification 

•  Forward  107  Disapproval 

•  Process  MAJCOM  Response  at  Wing 

•  Provide  Additional  Information 

•  Review  MAJCOM  Approval/Disapproval 

•  Submit  103  to  reflect  Possession  Change 

•  Process  107  Request  at  Depot 

•  Receive  1 07  Request  at  Depot 

•  Log-in  107 

•  Send  Copy  of  107  to  Engineering 

•  Evaluate  and  Make  Disposition  of  1 07 

•  Assign  Priority  to  107 

•  Assign  107  to  Engineer 

•  Log-in  to  Tracking  Database 

•  Prepare  Disposition 

•  Review  107  Request 

•  Review  Drawings  in  Data  Repository /TOs 

•  Request  Additional  Info  from  Field 

•  Develop  Repair 

•  Approve  Disposition 

•  Receive  MAJCOM  Cert/Disapproval 

•  Execute  Disposition  of  107 

•  Draft/Send  Repair  Disp  Message  to  Unit 

•  Prepare  Costing  &  Pers  Details  for  DFT 

•  Prepare  206  for  DFT  Deployment 

•  Request  Applicable  SOR 

•  Prepare  and  Ship  Tooling 

•  Deploy  DFT  if  applicable 

•  Process  Depot  Response  at  Wing 

•  Notify  Work  Center  of  Depot  Response 

•  Provide  Additional  Information 

•  Follow  Depot  Instructions 

•  Order  Parts  and/or  Equipment  as  Required 

•  Research  Required  Parts  and  Equipment 

•  Prepare  &  Submit  Order  for  Parts  &  Equip 

•  Receive  Ordered  Parts  and  Equipment 

•  Follow  up  on  Backordered  Parts/  Equip 
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•  Notify  Depot  of  Parts/Equipment  Receipt 

•  Repair  Item/Retum  to  Operation 

•  Complete  Temp  Fix  &  Send  Item  to  Depot 

•  Coord  Depot  Field  Team  Repair  Efforts 

•  Follow  Depot  Guidance  for  Local  Repair 

•  Continue  Operation  of  Item 

•  Permanently  Remove  from  Service 

•  Prepare  &  Submit  Supp  107  As  Reqd 

•  Verify  107  Completion 

•  Inspect  Repair  by  QA 

•  Review  Repair  Documentation 

•  Notify  MAJCOM/Depot  of  Completion 

•  Submit  1 03  to  reflect  Possession  Change 


Process:  Process  AFTO  107  Requests  for  Tech  Assist 


Description 

1 .  Procedures  for  processing  of  an  AFTO  1 07  request  for  technical  assistance  on 
aircraft/equipment/system  that  are  in  need  of  repair. 

Trigger 

1.  Aircraft  Failure  or  Problem 
Overview 

1.  Parent  Process:  Root 

2.  Number  of  Children:  12 

Process:  Determine  Repair  Needs 


Description 

1 .  Determine  the  specific  repair  needs  by  using  all  available  resources,  to  include 
CFT  if  available. 

Trigger 

1 .  Aircraft/Equipment/System  Failure  or  Problem 
Overview 

1 .  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

2.  Number  of  Children:  6 
Actors 

1 .  Q A  Personnel  - 

2.  Maintenance  Personnel  - 

3.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 
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Process:  Research  Repair  Requirements 


Description 

1 .  Check  specific  aircraft  Technical  Orders  and  other  related  materials  to  determine 
repair  procedures  and  level  of  repair  (local  or  depot)  allowed. 

Trigger 

1.  Aircraft/Equipment/System  Failure  or  Problem 
Overview 

1 .  Parent  Process:  Determine  Repair  Needs 

2.  Number  of  Children:  7 
Actors 

1.  Maintenance  Personnel  - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major 
Design  Series) 

3.  QA  Personnel  - 


Process:  Research  Repair  in  Technical  Orders 


Description 

1 .  Review  applicable  TO  to  verify  the  type,  procedures,  and  authorized  level  of 
repairs  required. 

Overview 

1 .  Parent  Process:  Research  Repair  Requirements 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/sy  stems 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  QA  Personnel  - 


Process:  Review  Other  Related  Manuals 


Description 

1 .  Check  message  files,  drawings,  manufacturer  manuals,  bulletins,  procedure  TO, 
and  Time  Compliance  TOs  for  assistance  in  determining  repair  procedures. 
Overview 

1 .  Parent  Process:  Research  Repair  Requirements 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 
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2.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Contact  Other  Bases  for  Similar  Problems 


Description 

1 .  Contact  other  Air  Force  bases,  Department  of  Defense,  and  government  services 
with  same  aircraft  that  may  have  had  similar  problems  and  request 
documentation,  when  available. 

Overview 

L  Parent  Process:  Research  Repair  Requirements 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  Maintenance  Personnel  from  other  bases  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  QA  Personnel  - 

Process:  Review  Maintenance  History 


Description 

1.  Review  maintenance  history  using  CAMS,  Aircraft  forms  (781's),  other  107's,  and 
shop  maintenance  history  for  past  repairs  of  a  similar  nature. 

Overview 

1 .  Parent  Process:  Research  Repair  Requirements 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

Process:  Determine  if  Capability  is  at  Base  Level 


Description 

1 .  Check  specific  aircraft  TO's  and  other  related  items,  verify  whether  or  not  the 
owning  work  center  has  equipment  and  knowledge  to  complete  repair.  This  would 
also  include  consulting  local  subject  matter  experts  AFETS/CETS  and  on-site 
CFT,  if  available. 

2.  CETS  -  Contract  Engineering  Technical  Services 
Overview 

1 .  Parent  Process:  Determine  Repair  Needs 

2.  Number  of  Children:  0 
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Actors 

1 .  Maintenance  Personnel  - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Contact  Depot  for  Special  Assistance 


Description 

1 .  Contact  Depot  Equipment  Specialists/Engineers  for  any  unclear  areas  in  the  TO's 
or  to  determine  if  Depot  will  allow  the  owning  work  center  to  accomplish  the 
repair. 

Overview 

1 .  Parent  Process:  Determine  Repair  Needs 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  QA  Personnel  - 


Process:  Determine  Parts  Availability 


Description 

1 .  Using  the  necessary  TO's,  determine  which  parts  are  needed  for  the  repair. 

Determine  if  the  needed  parts  are  available  at  the  owning  work  center  or 
elsewhere  on  base.  If  parts  are  not  available,  determine  if  they  are  procurable  or 
non-procurable. 

Resources 

1 .  Dollars  to  procure/ship  parts  can  be  a  problem,  especially  at  end  FY. 

Overview 

1 .  Parent  Process:  Determine  Repair  Needs 

2.  Number  of  Children:  0 

Actors 

1 .  Maintenance  Personnel  - 

2.  Supply  Personnel  - 

Process:  Determine  Equipment  Availability 

Description 

1 .  Verify  if  special  equipment  is  needed  using  TO's  (see  step  A1 .2).  If  equipment  is 
needed,  does  the  owning  work  center  have  the  equipment?  If  not,  does  anyone  on 
base?  If  not,  is  it  procurable  or  non-procurable? 

Resources 

1 .  Dollars  to  procure/ship  equipment  can  be  a  problem,  especially  at  end  FY. 
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Overview 

1 .  Parent  Process:  Determine  Repair  Needs 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel  - 

2.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Repair  Locally/Return  to  Operation 


Description 

1 .  After  a  review  of  the  local  repair  capability,  it  is  determined  that  the  aircraft  can 
be  fixed  on  site  by  local  mechanics/engineers  or  it  is  determined  that  the  aircraft 
does  not  need  to  be  repaired  at  this  time  and  can  be  returned  to  operations. 

Trigger 

1 .  Decision  to  Repair  Locally 
Overview 

1 .  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 

2.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  QA  Personnel  - 

Process:  Prepare  &  Submit  107  Request 


Description 

1 .  Wing  level  coordinated  effort  with  QA  product  improvement,  Wing  P&S,  owning 
unit/backshop  maintenance  personnel  and  AFETS.  QA's  product  improvement 
section  should  be  the  lead  for  preparing  and  submitting  the  AFTO  107  due  to  their 
technical  background.  Wing  P&S  should  have  secondary  responsibility  to  provide 
the  administrative  checks  and  balances  and  proper  notifications  required. 

2.  Responsibility  for  submission  of  AFTO  107s  varies  from  base  to  base  and  by 
MAJCOM.  For  example,  Tyndall  AFB  has  a  Depot  Liaison  who  is  not  part  of 
Wing  P&S  or  QA.  The  Depot  Liaison  processes  and  submits  all  107s. 

Trigger 

1 .  Decision  to  Request  Depot  Assistance 
Overview 

1.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 
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2.  Number  of  Children:  3 
Actors 

1 .  QA  Personnel  - 

2.  Wing  P&S  Personnel  - 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Produce  107  Narr  at  Work  Center  Level 


Description 

1 .  Create  a  narrative  for  the  1 07  request  form.  This  will  be  a  very  technically 

detailed  narrative  of  the  discrepancy.  Prescribed  format  in  T.O.  00-25-107  will  be 
used  as  a  guideline. 

Trigger 

1 .  Decision  to  request  Depot  repair  assistance 

Overview 

1 .  Parent  Process:  Prepare  &  Submit  107  Request 

2.  Number  of  Children:  2 
Actors 

1 .  Maintenance  Personnel  - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Describe  Problem 


Description 

1 .  List  detailed  description  and  location  of  the  discrepancy,  describe  the 

unsatisfactory  condition,  what  has  been  done  to  try  to  correct  it,  and  list  the  items 
that  are  damaged,  missing,  or  needing  repair. 

Overview 

1 .  Parent  Process:  Produce  1 07  Narr  at  Work  Center  Level 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 

2.  QA  Personnel  - 

Process:  Create  Drawings  &  Other  Items  Req  by  Depot 


Description 

1 .  Process  Name:  Create  Drawings,  Diagrams,  &  Other  Items  Requested  by  Depot 
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2.  Take  measurements  of  damage  or  defects  such  as  gaps,  tears  and  holes.  Include 
this  on  a  drawings  and  list  allowable  limits  from  TO's.  Take  pictures  (digital 
imaging)  and  create  other  visual  aids  that  make  the  problem  clearer. 

Overview 

1.  Parent  Process:  Produce  107  Narr  at  Work  Center  Level 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel  - 

2.  QA  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Prepare  Specific  Depot  Repair  Request 


Description 

1 .  List  what  you  expect  Depot  to  provide  you,  ask  for  guidance  on  level  of  repair, 
ask  them  to  determine  whether  system  is  still  usable,  and  for  any  temporary  repair 
procedures.  Include  information  concerning  any  upcoming  deployments,  phase 
inspections,  or  PDM  input. 

2.  Note:  Consider  recommending  change  to  TO  00-25-107  to  require  info  on 
upcoming  deployments,  phase  inspections,  or  PDM  input. 

Overview 

1.  Parent  Process:  Produce  107  Narr  at  Work  Center  Level 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Review  107  Narrative 


Description 

1 .  Review  1 07  narrative  with  owning  work  center  for  completeness  and  initiate  the 
local  107  checklist/worksheet. 

Trigger 

1 .  Receipt  of  107  Narrative  from  work  center  or  Request  for  additional  information 
Overview 

1.  Parent  Process:  Prepare  &  Submit  107  Request 

2.  Number  of  Children:  6 
Actors 

1.  Q A  Personnel - 

2.  Maintenance  Personnel  - 
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3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  Wing  P&S  Personnel  - 


Process:  Review  Narrative  for  Completeness 


Description 

1 .  Review  narrative  context  for  accuracy  and  ensure  description  of  the  problem  is 
complete.  Make  sure  all  supporting  documents  are  included. 

Overview 

1.  Parent  Process:  Review  107  Narrative 

2.  Number  of  Children:  0 
Actors 

1.  QA  Personnel  - 

2.  Maintenance  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Validate  Local  Resources 


Description 

1 .  Attempt  to  verify  which  equipment  and  parts  are  available  at  the  work  centers 
needed  to  complete  the  task. 

Overview 

1 .  Parent  Process:  Review  1 07  Narrative 

2.  Number  of  Children:  0 
Actors 

1 .  QA  Personnel  - 

2.  Maintenance  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Determine  Fleet  Implications 


Description 

1 .  Review  seriousness  of  the  problem,  and  determine  if  other  aircraft/equipment  may 
be  affected,  or  have  the  same  discrepancy. 

Overview 

1 .  Parent  Process:  Review  1 07  Narrative 

2.  Number  of  Children:  0 
Actors 

1.  QA  Personnel - 

2.  Maintenance  Personnel  - 
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3.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

4.  Wing  P&S  Personnel  - 

5.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Initiate  107  Checklist 


Description 

1.  Follow  step  by  step  instructions  on  107  Request  Checklist/Worksheet  as 
applicable  (see  for  example,  MHAFBI 21-172  Attachment  2  checklist). 

Overview 

1.  Parent  Process:  Review  107  Narrative 

2.  Number  of  Children:  0 
Actors 

1.  QA  Personnel  - 

Process:  Complete  107  &  Submit  Req  for  Assistance 


Description 

1 .  Process  Name:  Complete  107  and  Submit  Request  for  Assistance 

2.  Ensure  1 07  is  completed  and  submitted  in  the  correct  format  to 
MAJCOM/DEPOT. 

Trigger 

1.  Receipt  of  validated  107  narrative 

Overview 

1.  Parent  Process:  Prepare  &  Submit  107  Request 

2.  Number  of  Children:  3 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  QA  Personnel  - 


Process:  Review  107  Narr/Checklist  Completeness 


Description 

1.  Process  Name:  Review  107  Narrative  and  Checklist  for  Completeness 

2.  Check  107  request  form  for  completeness  and  accuracy.  Review  107  checklist  and 
all  supporting  materials  for  completeness. 

Overview 

1.  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel  - 
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2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 


Process:  Prepare  107  for  Transmission 


Description 

1 .  Prepare  E-Mail  or  Make  Cover  Sheet  for  FAX  and  put  1 07  request  in  message 
format  using  special  computer  program  (Sarah  Lite)  LAW  T.O.  00-25-107. 

2.  Note:  Need  to  explore  making  this  process  real-time.  As  an  interim  solution,  can 
an  Email  message  totally  replace  the  formal  Sarah  Lite  message? 

3.  Preferred  method  of  sending  request  to  MAJCOM  is  via  e-mail.  Reference:  Air 
Force  Instruction  (AFI)  33-12,  "Information  may  be  sent  between  offices  or 
individuals,  or  be  displayed  on  the  web.  The  Air  Force  goal  for  the  Internet  is  to 
provide  maximum  availability  at  acceptable  risk  levels  for  Air  Force  members 
needing  access  for  the  execution  of  official  business."  E-mail  transmission  allows 
for  use  of  digital  imaging  to  accompany  depot  maintenance  requests. 

Overview 

1 .  Parent  Process:  Complete  1 07  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel - 

Process:  Submit  107  to  MAJCOM/Depot 


Description 

1 .  Send  completed  1 07  and  supporting  materials  to  MAJCOM/Depot  via  FAX,  E- 
Mail,  or  Base  Communication  Center. 

2.  Preferred  method  of  sending  request  to  MAJCOM  is  via  e-mail 

3.  Occasionally,  107  requests  are  sent  directly  to  depot  without  going  through  proper 
channels.  Proper  Procedures  for  Requesting  Depot  Maintenance  Assistance 

•  Technical  assistance  requests  will  be  forwarded  directly  to  the  depot  unless 
directed  by  MAJCOM 

•  0&  I  Level  maintenance  requests  will  be  forwarded  to  the  MAJCOM  for 
certification 

•  Unprogrammed  depot  level  maintenance  requests  will  be  submitted  through  the 
MAJCOM  for  certification 

•  Re:  T.O.  00-25-107,  para  6.1, 6.2,  6.3 
Overview 

1 .  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel - 

2.  Wing  P&S  Personnel  - 
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Process:  Verify  with  MAJCOM/Depot  Receipt  of  107 


Description 

1 .  Contact  MAJCOM/Depot  via  Land  Line  or  other  means  to  ensure  they  received 
107. 

2.  Note:  If  EMail  was  used,  the  Return  Receipt  capability  will  automatically  provide 
this  functionality. 

Overview 

1.  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel  - 

2.  Wing  P&S  Personnel  - 

Process:  Change  Aircraft/Equipment  Possession 


Description 

1 .  Wing  P&S  submits  AFI 21-103  change  of  possession  (e.g.,  BQ  -  waiting  AFMC 
action/decision). 

Trigger 

1 .  Notification  of  1 07  Submission 

Overview 

1.  Parent  Process:  Prepare  &  Submit  107  Request 

2.  Number  of  Children:  0 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  QA  Personnel  - 

3.  Maintenance  Personnel  - 

4.  MOC  -  Maintenance  Operations  Center  (Track  Status  of 
Aircraft/Equipment/System  on  a  real  time  basis) 

Process:  Process  107  Request  at  MAJCOM 


Trigger 

1 .  Receipt  of  1 07  Request 
Overview 

1 .  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

2.  Number  of  Children:  2 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 
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Process:  Receive  107  at  MAJCOM 

Description 

1 .  AFTO  107  submitted  by  Wing  is  received  at  MAJCOM  by  either  through  E-mail 
or  FAX. 

Trigger 

1 .  Receipt  of  1 07  Request 
Overview 

1 .  Parent  Process:  Process  1 07  Request  at  MAJCOM 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Evaluate  107  Request 

Description 

1 .  Ensure  necessary  information  is  included  to  help  engineers  determine  repair 
disposition 

2.  Validate  Date  Time  Group  on  Official  Message  is  correct 
Overview 

1 .  Parent  Process:  Process  1 07  Request  at  MAJCOM 

2.  Number  of  Children:  3 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Validate  107 


Description 

1.  Validate  Date  Time  Group  is  correct 
Overview 

1.  Parent  Process:  Evaluate  107  Request 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Research  107 

Description 

1 .  Make  sure  all  necessary  information  is  included  on  the  message  to  help  engineers 
make  proper  repair  disposition 
Overview 

1 .  Parent  Process:  Evaluate  107  Request 

2.  Number  of  Children:  0 
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Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Request  Additional  Information  from  Unit 


Description 

1 .  If  necessary,  request  additional  information  from  the  field  (e.g.,  pictures  or 
diagrams)  to  help  engineers  formulate  repair  procedures. 

Overview 

1.  Parent  Process:  Evaluate  107  Request 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Certify  funding  is  available  for  repair 


Description 

1 .  Ensure  sufficient  DPEM  (Depot  Purchased  Equipment  Maintenance)  is  available 
to  fund  repair. 

Overview 

1.  Parent  Process:  Evaluate  107  Request 

2.  Number  of  Children:  1 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Cost  estimate  pre-certification 


Description 

1 .  Air  National  Guard  and  AFMC  requires  cost  estimate  from  the  Depot  prior  to 
MAJCOM  Certification  to  verify  if  funds  are  available 

2.  AETC  occasionally  request  cost  estimate  to  determine  available  funding. 
Overview 

1 .  Parent  Process:  Certify  funding  is  available  for  repair 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Review  Cost  Prohibitive  Estimates 


Description 

1 .  Coordinate  with  Air  Staff  for  possible  attrition  action  if  cost  to  repair  exceeds 
economic  limits. 

Trigger 

1.  Extensive  damage  causing  prohibitive  cost 
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Overview 

1 .  Parent  Process:  Certify  funding  is  available  for  repair 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Execute  107  Disposition 

Description 

1 .  MAJCOM  MDS/System  Functional  Manager  coordinates  and  sends  request  to 
depot 
Trigger 

1 .  Completion  of  MAJCOM  Evaluation 
Overview 

1 .  Parent  Process:  Process  1 07  Request  at  MAJCOM 

2.  Number  of  Children:  1 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Forward  107  Certification 

Description 

1 .  MAJCOM  sends  107  Certification  Message  to  depot  with  CC  to  unit. 

Overview 

1 .  Parent  Process:  Execute  1 07  Disposition 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Forward  107  Disapproval 

Description 

1 .  Send  disapproval  to  unit  with  CC  to  depot.  Notify  unit  to  accurately  document 
time  taken  for  an  erroneous  possession. 

2.  Note:  May  be  some  differences  on  TO/CC  for  individual  MAJCOMs. 

Overview 

1 .  Parent  Process:  Execute  1 07  Disposition 

2.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

Process:  Process  MAJCOM  Response  at  Wing 
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Description 

1 .  Disseminate  to  key  players  MAJCOM's  response  to  the  submitted  107. 

Trigger 

1 .  Receipt  of  MAJCOM  Response  or  Request  for  Additional  Information 
Overview 

1 .  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

2.  Number  of  Children:  2 
Actors 

1.  QA  Personnel  - 

2.  Wing  P&S  Personnel  - 

3.  Maintenance  Personnel  - 

Process:  Provide  Additional  Information 


Description 

1 .  As  requested,  provide  any  additional  information  to  MAJCOM.  Contact  key 
players  for  help. 

Trigger 

1 .  MAJCOM  Request  for  Additional  Information 
Overview 

1 .  Parent  Process:  Process  MAJCOM  Response  at  Wing 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

3.  QA  Personnel  - 

Process:  Review  MAJCOM  Approval/Disapproval 


Description 

1 .  Review  the  Approval/Disapproval  decision  from  MAJCOM.  Request  clarification 
if  needed. 

Trigger 

1 .  Receipt  of  MAJCOM  Response 
Overview 

1 .  Parent  Process:  Process  MAJCOM  Response  at  Wing 

2.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel - 

2.  Wing  P&S  Personnel  - 

3.  Maintenance  Personnel  - 

Process:  Submit  103  to  reflect  Possession  Change 
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Description 

1 .  If  1 07  disapproved,  Wing  P&S  submits  AFI 21-103  returning  system  to 
appropriate  possession  code. 

Trigger 

1 .  Receipt  MAJCOM  Response 
Overview 

1 .  Parent  Process:  Process  MAJCOM  Response  at  Wing 

2.  Number  of  Children:  0 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  Maintenance  Personnel  - 

3.  MOC  -  Maintenance  Operations  Center  (Track  Status  of 
Aircraft/Equipment/System  on  a  real  time  basis) 


Process:  Process  107  Request  at  Depot 


Description 

1 .  Receive  1 07  request  from  Unit/M  A  JCOM  and  prepare  repair  disposition. 

Trigger 

1 .  Receipt  of  1 07  Request 
Overview 

1 .  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

2.  Number  of  Children:  3 
Actors 

1 .  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

2.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 


Process:  Receive  107  Request  at  Depot 

Description 

1 .  Receive  1 07  from  unit  via  official  formal  message,  e-mail  or  fax. 

Trigger 

1 .  Receipt  of  1 07  Request 
Overview 

1 .  Parent  Process:  Process  1 07  Request  at  Depot 

2.  Number  of  Children:  1 
Actors 

1 .  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Log-in  107 

Description 

1 .  Receive  107  from  unit  and  log-in  to  database  system  and/or  manual  system. 

Appendix  A 


98 


Overview 

1.  Parent  Process:  Receive  107  Request  at  Depot 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  1 07  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Send  Copy  of  107  to  Engineering 


Description 

1 .  A  memo  requesting  repair  disposition,  including  parts  list  plus  any  applicable 
T.O.  figure  and  index,  grounding  or  flying  decision,  and  SOR  (Source  of  repair: 
CFT/DFT/O&I/PDM/DIM,  etc.)  is  attached  to  the  -107  and  sent  to  engineering 
via  e-mail  or  fax. 

Overview 

1 .  Parent  Process:  Receive  107  Request  at  Depot 

2.  Number  of  Children:  0 
Actors 

1.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Evaluate  and  Make  Disposition  of  107 


Description 

1 .  Review  1 07  and  prepare  repair  disposition.  This  includes  the  type  of  repair,  level 
of  repair,  status  of  aircraft  (grounded,  flyable)  or  equipment/system,  and 
parts/tooling  requirements.  Disposition  is  sent  to  Depot  1 07  Program  Manager 
(e.g.,  LFPLW  at  WR-ALC)  when  completed. 

Trigger 

1 .  Receipt  of  1 07  from  Depot  1 07  Program  Mgt  Personnel 
Overview 

1.  Parent  Process:  Process  107  Request  at  Depot 

2.  Number  of  Children:  4 
Actors 

1.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

Process:  Assign  Priority  to  107 


Description 

1 .  After  the  initial  review  of  the  1 07  request,  the  supervisor  assigns  a  priority  to  this 
107  request. 

2.  The  priority  assigned  to  the  1 07  request  can  be  influenced  by  importance  of  the 
aircraft/equipment/system  to  the  mission,  input  from  Commanders,  and  input 
from  MAJCOM  POCs. 

Overview 

1.  Parent  Process:  Evaluate  and  Make  Disposition  of  107 
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2.  Number  of  Children:  0 
Actors 

1 .  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Assign  107  to  Engineer 

Description 

1 .  Determine  which  engineer  has  the  expertise  and/or  time  to  work  the  1 07 
Overview 

1 .  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Log-in  to  Tracking  Database 

Description 

1.  Log  the  107  in  to  the  engineering  database 
Overview 

1 .  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Prepare  Disposition 


Description 

1 .  Engineer  conducts  the  necessary  research,  analysis,  design  and  coordination  to 
prepare  the  disposition 
Overview 

1 .  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

2.  Number  of  Children:  3 
Actors 

1 .  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

2.  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Review  107  Request 

Description 

1 .  Assigned  engineer  receives  the  1 07  request,  reads  the  request  and  determines  the 
next  action. 

Overview 

1 .  Parent  Process:  Prepare  Disposition 
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2.  Number  of  Children:  0 
Actors 

1.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

Process:  Review  Drawings  in  Data  Repository/TOs 

Description 

1 .  Detailed  drawings  are  available  in  the  Data  Repository  and/or  TOs  and  are 
reviewed  as  part  of  the  process  of  developing  the  repair  disposition. 

Overview 

1.  Parent  Process:  Prepare  Disposition 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

2.  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Request  Additional  Info  from  Field 


Description 

1 .  After  reviewing  the  107  request,  additional  information  may  be  requested  from 
the  field  unit  that  submitted  the  request. 

Overview 

1.  Parent  Process:  Prepare  Disposition 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

2.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Develop  Repair 

Description 

1 .  After  all  of  the  information  is  received  and  reviewed,  a  repair  plan  is  developed 
by  the  engineer  that  details  what  needs  to  be  done  and  which  SOR  will 
accomplish  the  repair. 

Overview 

1 .  Parent  Process:  Prepare  Disposition 

2.  Number  of  Children:  0 

Actors 

1 .  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

2.  Depot  Supervisor  or  Lead  Engineer  - 
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Process:  Approve  Disposition 

Description 

1 .  Supervisory  or  lead  engineer  reviews  the  disposition  for  technical  adequacy. 

Overview 

1 .  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Receive  MAJCOM  Cert/Disapproval 

Description 

1 .  Receive  MAJCOM  Certification  of  Disapproval. 

Trigger 

1 .  Receipt  of  MAJCOM  Certification/Disapproval 
Overview 

1 .  Parent  Process:  Process  1 07  Request  at  Depot 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Execute  Disposition  of  107 

Description 

1 .  Carry-out  the  disposition  of  the  107.  This  can  include  field-level  repairs,  depot 
drop-in  maintenance,  depot-level  repair,  satisfactory  as-is,  or  repair  by  contract 
field  team. 

Trigger 

1 .  Receipt  of  Disposition  from  Depot  Engineering  Personnel 
Overview 

1 .  Parent  Process:  Process  1 07  Request  at  Depot 

2.  Number  of  Children:  5 
Actors 

1 .  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Draft/Send  Repair  Disp  Message  to  Unit 

Description 

1 .  Send  courtesy  copy  of  engineering  repair  disposition  to  unit  and  MAJCOM  via  e- 
mail  or  fax  prior  to  official  message. 

2.  Prepare  and  send  official  formal  message  to  MAJCOM  with  CC  to  unit  stating  the 
disposition  of  the  repair  (type  of  repair,  level  of  repair,  flying  status  (grounded  or 
flying),  and  parts/tooling  required). 
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3.  If  MAJCOM  disapproved  107,  formal  message  sent  closing  107  action. 

4.  Preferred  method  of  transmission  is  through  E-Mail 

Overview 

1 .  Parent  Process :  Execute  Disposition  of  1 07 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  1 07  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Prepare  Costing  &  Pers  Details  for  DFT 


Description 

1 .  Prepare  Costing  and  Personnel  Details  of  DFT 

2.  Determine  the  cost  of  the  repair,  the  personnel  required,  and  the  number  of  man¬ 
hours  to  complete  the  repair.  This  work  is  accomplished  by  the  Workload/Planner 
and  is  done  when  a  DFT  will  perform  the  repair. 

Trigger 

1 .  SOR  Decision  =  DFT 
Overview 

1 .  Parent  Process:  Execute  Disposition  of  107 

2.  Number  of  Children:  0 
Actors 

1.  Depot  Workloader/Planner  - 

Process:  Prepare  206  for  DFT  Deployment 


Description 

1 .  Complete  the  AFLC  Form  206  electronically  and  forward  to  Program/Funds 
Control  Division  (LFC  at  WR-ALC).  The  206  is  a  Temporary  Work  Request  and 
vehicle/document  that  funds  the  applicable  source  of  repair  to  repair  the 
aircraft/equipment/system. 

Trigger 

1 .  SOR  Decision  =  DFT 
Overview 

1 .  Parent  Process:  Execute  Disposition  of  1 07 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Request  Applicable  SOR 


Description 

1.  Request  the  applicable  source  of  repair  (SOR)  that  will  complete  the  repair.  The 
depot  field  team  (DFT)  can  include  personnel  from  the  Combat  Logistics  Support 
Squadron  (CLSS)  or  from  civilian  personnel. 
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2.  Source  of  Repair  (SOR)  definitions  -  Depot  field  team  (DFT),  Contract  field  team 
(CFT),  Organizational  and  Intermediate  (O&I),  Program  Depot  Maintenance 
(PDM),  Drop-In-Maintenance  (DIM),  Aircraft  Damage  Repair  (ADR). 

Overview 

1 .  Parent  Process:  Execute  Disposition  of  1 07 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Workloader/Planner  - 

2.  Depot  Contract  Field  Team  Program  Manage  - 

Process:  Prepare  and  Ship  Tooling 

Description 

1 .  Based  upon  the  requirements  of  the  repair,  Production  Support  Branch  (e.g., 
LFPSI  at  WR-ALC)  will  assemble  and  ship  required  special  tooling  to  the  unit. 
Overview 

1 .  Parent  Process:  Execute  Disposition  of  1 07 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Workloader/Planner  - 

2.  Depot  Transportation  Personnel  - 

Process:  Deploy  DFT  if  applicable 

Description 

1 .  Upon  verification  that  all  parts  and  equipment  are  on-site  at  the  unit,  the  DFT  is 
deployed  via  commercial/military  air  or  POV  to  make  the  repair.  This  process 
only  takes  place  If  DFT  has  been  identified  as  the  repair  source. 

Trigger 

1 .  SOR  Decision  =  DFT 
Overview 

1 .  Parent  Process:  Execute  Disposition  of  1 07 

2.  Number  of  Children:  0 
Actors 

1 .  Depot  Field  Team  - 

Process:  Process  Depot  Response  at  Wing 


Description 

1 .  Review  response  from  Depot  and  provide  additional  information,  as  needed. 
Follow  all  instructions  received  from  the  Depot.  Disposition  could  require  any  of 
the  following  actions: 

•  Order  parts  and/or  equipment 

•  Complete  the  repair  locally  under  direction  of  Depot 
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•  Assist  as  needed  in  the  repair  efforts  of  the  Depot  Field  Team 

•  Perform  temporary  fix  and  send  to  Depot  for  repairs 

•  Continue  operation  without  repairs,  at  this  time  -  Permanently  remove  item  from 
service. 

Trigger 

1 .  Receipt  of  Depot  Response  or  Request  for  Additional  Information 
Overview 

1 .  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

2.  Number  of  Children:  2 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  QA  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  Maintenance  Personnel  - 

Process:  Notify  Work  Center  of  Depot  Response 


Description 

1 .  Notify  work  center  of  any  response  received  from  Depot  and  take  appropriate 
action. 

Overview 

1 .  Parent  Process:  Process  Depot  Response  at  Wing 

2.  Number  of  Children:  0 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  QA  Personnel  - 

Process:  Provide  Additional  Information 


Description 

1 .  Provide  any  additional  information  requested  by  the  Depot.  Contact  appropriate 
work  center  for  additional  information  and  submit  information  to  Depot. 
Trigger 

1 .  Request  for  Additional  Information 
Overview 

1 .  Parent  Process:  Process  Depot  Response  at  Wing 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 
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Process:  Follow  Depot  Instructions 


Description 

1 .  Follow  all  instructions  received  from  the  Depot  pertaining  to  the  repair  or 
continued  use  of  the  equipment. 

Trigger 

1 .  Receipt  of  Depot  Response 
Overview 

1 .  Parent  Process:  Process  Depot  Response  at  Wing 

2.  Number  of  Children:  1 
Actors 

1.  Maintenance  Personnel - 

2.  Wing  P&S  Personnel  - 

3.  QA  Personnel  - 

Process:  Order  Parts  and/or  Equipment  as  Required 

Description 

1 .  Research  and  order  any  parts  and/or  equipment  required  by  the  Depot  or  work 
center  to  accomplish  repair,  if  not  already  on  hand.  Parts  may  be  issued  or  be 
backordered  and  require  lots  of  waiting. 

Overview 

1 .  Parent  Process :  Follow  Depot  Instructions 

2.  Number  of  Children:  4 
Actors 

1.  Maintenance  Personnel - 

2.  Supply  Personnel  - 

Process:  Research  Required  Parts  and  Equipment 

Description 

1 .  Find  Stock  or  Part  Numbers  for  the  Parts  or  Equipment  by  using  TO's,  FedLog, 
and/or  calling  Depot  for  information. 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 

Process:  Prepare  &  Submit  Order  for  Parts  &  Equip 

Description 

1.  Prepare  necessary  documents  to  order  the  required  parts  and/or  equipment  and 
submit  it  to  appropriate  agencies. 
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2.  Note:  Depot  may  or  may  not  provide  parts  themselves  depending  on  funding  and 
parts  availability  (e.g.,  depot  may  need  to  manufacture  parts). 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel  - 

2.  Supply  Personnel  - 


Process:  Receive  Ordered  Parts  and  Equipment 


Description 

1 .  Receive  the  Parts/Equipment  from  Base  Supply  stock,  from  other  bases,  from  the 
manufacturer  or  from  the  Depot. 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  Supply  Personnel  - 

Process:  Follow  up  on  Backordered  Parts/  Equip 


Description 

1 .  If  the  Parts  or  equipment  are  not  available,  then  Supply  will  go  to  other  bases,  to 
the  Depot,  or  to  the  manufacturer  to  retrieve  them.  The  owning  work  center  will 
keep  track  of  the  supplies  that  have  not  been  issued  by  using  a  supply  document 
number. 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

Process:  Notify  Depot  of  Parts/Equipment  Receipt 


Description 

1 .  Notify  Depot  when  all  parts/hardware  and  applicable  tooling/equipment  are  on 
site. 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 
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Actors 

1 .  Maintenance  Personnel  - 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 

Process:  Repair  Item/Return  to  Operation 

Description 

1 .  Repair  aircraft/equipment/system  as  directed  and/or  return  to  operation. 

Overview 

1 .  Parent  Process:  Follow  Depot  Instructions 

2.  Number  of  Children:  4 
Actors 

1 .  Maintenance  Personnel  - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

Process:  Complete  Temp  Fix  &  Send  Item  to  Depot 

Description 

1 .  Follow  all  directions  from  Depot  to  accomplish  a  temporary  fix  of  the  problem. 
Send  aircraft/equipment/system  to  Depot  as  required  by  Depot  schedule. 
Overview 

1 .  Parent  Process:  Repair  Item/Retum  to  Operation 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

3.  QA  Personnel  - 

Process:  Coord  Depot  Field  Team  Repair  Efforts 

Description 

1 .  Process  Name:  Coordinate  Depot  Field  Team  Repair  Efforts 

2.  After  the  initial  meeting,  coordinate  with  Depot,  work  center  and  any  other  shops 
required  on  when,  where,  and  how  the  repair  by  the  Depot  Field  Team  will  be 
accomplished. 

Overview 

1 .  Parent  Process:  Repair  Item/Retum  to  Operation 

2.  Number  of  Children:  0 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  QA  Personnel  - 

3.  Maintenance  Personnel - 
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4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

5.  Depot  Field  Team  - 

Process:  Follow  Depot  Guidance  for  Local  Repair 


Description 

1 .  Follow  the  guidance  and  repair  action  received  from  Depot  to  accomplish  any 
O&l  level  repair  of  the  aircraft/equipment/system. 

Overview 

1 .  Parent  Process :  Repair  Item/Retum  to  Operation 

2.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  QA  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Continue  Operation  of  Item 

Description 

1 .  Follow  all  guidance  received  from  Depot  for  continued  operation  of  the 
'Satisfactory  As-Is'  aircraft/equipment/system. 

Overview 

1 .  Parent  Process:  Repair  Item/Retum  to  Operation 

2.  Number  of  Children:  0 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  Maintenance  Personnel  - 

Process:  Permanently  Remove  from  Service 


Description 

1 .  If  determination  is  made  that  it  is  not  economically  feasible  to  repair,  permanently 
remove  aircraft/equipment/system  from  service. 

Overview 

1 .  Parent  Process:  Repair  Item/Retum  to  Operation 

2.  Number  of  Children:  0 
Actors 

1.  Air  Staff - 

2.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

3.  Maintenance  Personnel  - 

4.  Wing  P&S  Personnel  - 
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Process:  Prepare  &  Submit  Supp  107  As  Reqd 

Description 

1 .  If  additional  discrepancy  discovered  during  repair,  prepare  and  submit 
supplemental  (new)  107  as  previously  defined. 

Trigger 

1 .  Identification  of  additional  discrepancies  during  repair  process 
Overview 

1 .  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

2.  Number  of  Children:  0 
Actors 

1.  Maintenance  Personnel - 

2.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

3.  QA  Personnel  - 

Process:  Verify  107  Completion 

Description 

1 .  Ensure  that  all  maintenance  repair  actions  have  been  completed  and  that  all 
documentation  is  signed. 

Trigger 

1 .  Repair  action  completed 
Overview 

1 .  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

2.  Number  of  Children:  3 
Actors 

1.  QA  Personnel  - 

2.  Maintenance  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  Wing  P&S  Personnel  - 

Process:  Inspect  Repair  by  QA 

Description 

1 .  Q A  inspector  checks  repair  work  to  ensure  that  all  required  work/repair  has  been 
completed  in  a  satisfactory  manner  and  all  required  documentation  is  completed. 
Arrive  at  an  acceptable  solution  if  repair  is  not  acceptable. 

Overview 

1.  Parent  Process:  Verify  107  Completion 

2.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel - 
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Process:  Review  Repair  Documentation 


Description 

1 .  Review  appropriate  repair  documentation.  Maintain  copy  for  Base  Historical 
records. 

Overview 

1 .  Parent  Process :  V erify  1 07  Completion 

2.  Number  of  Children:  0 
Actors 

1 .  Q A  Personnel  - 

2.  Wing  P&S  Personnel  - 

Process:  Notify  MAJCOM/Depot  of  Completion 


Description 

1 .  Send  final  message  to  MAJCOM/Depot  of  completion  of  the  work  outlined  in  the 
107. 

2.  Note:  This  is  currently  not  being  done  by  the  Wing  with  regularity. 

Overview 

1.  Parent  Process:  Verify  107  Completion 

2.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel - 

2.  Wing  P&S  Personnel  - 


Process:  Submit  103  to  reflect  Possession  Change 


Description 

1.  Wing  P&S  submits  AFI 21-103  to  return  aircrafVequipment/system  to  owning 
unit  possession. 

Overview 

1.  Parent  Process:  Verify  107  Completion 

2.  Number  of  Children:  0 
Actors 

1 .  Wing  P&S  Personnel  - 

2.  MOC  -  Maintenance  Operations  Center  (Track  Status  of 
Aircraft/Equipment/System  on  a  real  time  basis) 

3.  Maintenance  Personnel  - 

4.  QA  Personnel  - 
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AFTO  107  Process  -  Problems/Solutions 

Process  AFTO  107  Requests  for  Tech  Assist 

Problem:  The  whole  AFTO  107  submission  process  is  too  slow  and  time 
consuming.  There  is  a  valid  need  to  folly  automate  the  system  to  provide 
management  with  real  time,  quick  decision  making  capability.  Loop  the 
unit/MAJCOM/Depot  into  a  real  time  system. 

Determine  Repair  Needs 

Research  Repair  Requirements 

Research  Repair  in  Technical  Orders 

Review  Other  Related  Manuals 

Contact  Other  Bases  for  Similar  Problems 

Review  Maintenance  History 

Problem:  Current  data  bases  are  not  user  friendly  which  causes  errors 
or  blanks  in  maintenance  history. 

Determine  if  Capability  is  at  Base  Level 

Contact  Depot  for  Special  Assistance 

Problem:  Contact,  details,  direction,  etc.  not  always  captured  by 
individuals/shops/units  make  first  contact  which  is  lost  to  management  as 
possible  use  in  decision  metrics. 

Determine  Parts  Availability 

Determine  Equipment  Availability 

Repair  Locally/Return  to  Operation 

Many  times  local  repair  is  not  considered  because  Wing  lacks  a  special  tool  or 
jig.  Giving  the  Wings  access  to  these  tools  would  result  in  more  local  repairs. 

Wings  can  approach  Companies,  i.e.  Boeing,  and/or  specific  depots,  i.e.  WR- 
ALC,  to  inquire  about  purchasing  or  manufacturing  their  own  "special 
tooling".  Drawings  and/or  specific  information  can  be  obtained  through  these 
services. 

Prepare  &  Submit  107  Request 
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Problem:  Focal  point  for  release  of  depot  maintenance  assistance  request  is 
not  standardized. 

Possible  solution:  Supplement  TO  00-25-107  with  MAJCOM  supplements. 

Problem:  Air  Staff  needs  to  standardize  at  wing  level  who  is  technically 
responsible/capable  of  providing  the  most  descriptively  thorough  107. 
Opinion  of  this  working  group  is  that  QA  is  best  choice  and  not  P&S. 

Problem:  107  submission  process  is  slow.... need  to  develop  an  on-line,  real¬ 
time  video  conferencing  capability  to  join  unit/MAJCOM/Depot  decision 
makers  for  fast  disposition. 

Produce  107  Narr  at  Work  Center  Level 

Describe  Problem 

Create  Drawings  &  Other  Items  Req  by  Depot 

Problem:  Due  to  current  107  submittal  process,  new  technology  is  not 
always  use  to  transmit  necessary  information  for  use  by  depots.. ..i.e. 
digital  camera  shots. 

Prepare  Specific  Depot  Repair  Request 
Review  107  Narrative 

Problem:  TO  00-25-107  gives  a  specific  format  for  requesting  O&I  level 
maintenance  assistance,  para  6.2.  It  does  not  give  a  format  for  requesting 
depot  level  maintenance  assistance. 

Possible  solution:  Submit  AFTO  FORM  22  to  insert  proper  format  for 
both  types  of  maintenance  requests. 

Review  Narrative  for  Completeness 

Validate  Local  Resources 

Determine  Fleet  Implications 

Initiate  107  Checklist 

Problem:  Not  all  wings  use  checklist/sheet  when  processing  107s 
causing  less  than  optimum  input/concerns/information  to 
MAJCOMs/depot 

Complete  107  &  Submit  Req  for  Assistance 
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Problem:  Air  Staff  needs  to  develop  new  program  for  107  submittal  based 
on  computer  program  that  requires  all  information  be  addressed  before 
107  can  be  submitted. 

Review  107  Narr/Checklist  Completeness 

Problem:  Para  7.1,  TO  00-25-107,  Format  for  submitting  maintenance 
assistance,  does  not  consider  PDM  input/deployment/phase  time  as  a 
factor  in  determining  economy  of  repair. 

Possible  solution:  AFTO  FORM  22,  TO  00-25-107,  to  change  this 
para  to  reflect  these  considerations. 

Prepare  107  for  Transmission 

Submit  107  to  MAJCOM/Depot 

Problem:  When  requesting  Unprogrammed  depot  level  maintenance 
assistance,  the  requirement  to  use  a  message  is  unnecessary. 
"Messaging"  requires  use  of  SARA  LITE  which  has  always  been 
awkward  and  time  consuming  to  use.  Current  authorized  process  of  e- 
mail  "heads  up  copy",  followed  by  a  formal  message  is  duplication  of 
effort.  Use  of  e-mail  would  increase  the  speed  of  disposition  and 
provide  the  opportunity  to  exploit  the  benefit  of  digital  imaging. 

Possible  solution:  AFTO  FORM  22  to  change  TO  00-25-107,  para 
6.2,  to  allow  e-mail  transmission  of  request  in  format  specified  in  para 
7. 

Verify  with  MAJCOM/Depot  Receipt  of  107 

Problem:  Lack  of  automated  107  submission  negates  quick  feedback 
loop  to  verify  receipt. 

Change  Aircraft/Equipment  Possession 
Process  107  Request  at  MAJCOM 
Receive  107  at  MAJCOM 
Evaluate  107  Request 
Validate  107 
Research  107 
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Request  Additional  Information  from  Unit 

Certify  funding  is  available  for  repair 

Problem:  TO  00-25-107,  para  6.2  mentions  certification  by  MAJCOM 
that  all  resources  have  been  exhausted.  It  is  assumed  this  certification  also 
considers  available  funding.  Para  6.3,  with  potentially  much  higher  costs, 
makes  no  mention  of  "certification." 

Possible  solution:  AFTO  FORM  22  to  TO  0-25-107  to  standardize  these 
two  paragraphs. 

Cost  estimate  pre-certification 
Review  Cost  Prohibitive  Estimates 
Execute  107  Disposition 
Forward  107  Certification 
Forward  107  Disapproval 
Process  MAJCOM  Response  at  Wing 
Provide  Additional  Information 
Review  MAJCOM  Approval/Disapproval 

Submit  103  to  reflect  Possession  Change 

Problem:  Loss  of  accurate  reporting  status  due  to  slow  107  process.... need 
to  automate  whole  process. 

Process  107  Request  at  Depot 

Receive  107  Request  at  Depot 

Log-in  107 

Send  Copy  of  107  to  Engineering 
Evaluate  and  Make  Disposition  of  107 
Assign  Priority  to  107 
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Assign  107  to  Engineer 
Log-in  to  Tracking  Database 
Prepare  Disposition 
Review  107  Request 

Review  Drawings  in  Data  Repository/TOs 
Request  Additional  Info  from  Field 
Develop  Repair 
Approve  Disposition 

Receive  MAJCOM  Certification/Disapproval 
Execute  Disposition  of  107 

Draft/Send  Repair  Disp  Message  to  Unit 
Prepare  Costing  &  Pers  Details  for  DFT 
Prepare  206  for  DFT  Deployment 
Request  Applicable  SOR 
Prepare  and  Ship  Tooling 
Deploy  DFT  if  applicable 
Process  Depot  Response  at  Wing 

Notify  Work  Center  of  Depot  Response 
Provide  Additional  Information 
Follow  Depot  Instructions 

Order  Parts  and/or  Equipment  as  Required 
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Research  Required  Parts  and  Equipment 
Prepare  &  Submit  Order  for  Parts  &  Equip 
Receive  Ordered  Parts  and  Equipment 
Follow  up  on  Backordered  Parts/  Equip 
Notify  Depot  of  Parts/Equipment  Receipt 
Repair  Item/Return  to  Operation 

Complete  Temp  Fix  &  Send  Item  to  Depot 
Coord  Depot  Field  Team  Repair  Efforts 
Follow  Depot  Guidance  for  Local  Repair 
Continue  Operation  of  Item 
Permanently  Remove  from  Service 
Prepare  &  Submit  Supp  107  As  Reqd 
Verify  107  Completion 
Inspect  Repair  by  QA 
Review  Repair  Documentation 
Notify  MAJCOM/Depot  of  Completion 
Submit  103  to  reflect  Possession  Change 
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Kick-Off  Session  Evaluation  -  Survey  Results 
Tool  Functionality 


1.  The  system  allowed  me  to  do  everything  I  needed  to  develop  the  process  model. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 

m 

D(2) 

SD(1) 


Count 

1 

5 

0 

0 

0 


Statistics 

Mean  A(4.17) 

STD  0.41 


2.  Developing  the  process  model  using  this  tool  was: 

Very  Easy  (VE),  Easy  (E),  Average  (A),  Hard  (H),  Very  Hard  (VH) 


Choices 

VE(5) 

E(4) 

A  (3) 
H(2) 
VH(1) 


Count 

2 

4 

0 

0 

0 


Statistics 

Mean  E(4.33) 

STD  0.52 


3.  What  additional  features  would  make  it  easier  to  develop  a  process  model  using 
this  tool?  (Open-Ended) 

1.  using  a  format  similar  to  MICROFAX  Form  Flow 

2.  The  availability  to  Cut  and  Paste  would  be  useful. 

If  the  screen  would  not  reset  every  time  someone  made  an  input  it  would  be  easier 
to  work. 

3.  Higher  levels  of  authority....i.e.  Air  Staff  representation  to  make  decisions  for 
further  development/improvements  of/to  the  AFTO  107  process. 

4.  Longer  advance  briefing 


Tool  Usability 
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4.  The  screen  layout/design  was  clear  and  easy  to  use. 

SA-Strongly  Agree  A- Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 

N(3) 

D(2) 

SD(1) 

Statistics 

Mean 

STD 


Count 

3 

3 

0 

0 

0 


SA(4.50) 

0.55 


5.  What  changes  to  the  screen  layout  would  make  the  tool  easier  to  use?  (Open- 
Ended) 

1 .  Eliminate  the  blanking  out  screen  and  having  to  scroll  down  after  each 
submission 

2.  Cut  and  paste. 

Group  selections/assembly 

3.  The  process  tree  could  be  centered  better 

6.  Understanding  the  instructions  provided  by  the  tool  was: 

Very  Easy  (VE),  Easy  (E),  Average  (A),  Hard  (H),  Very  Hard  (VH) 


Choices 

VE(5) 

E(4) 

A  (3) 

H(2) 

VH(1) 

Statistics 

Mean 

STD 


Count 

2 

3 

1 

0 

0 


E(4.17) 

0.75 


7.  If  you  encountered  any  errors,  understanding  the  error  messages  was: 

Very  Easy  (VE),  Easy  (E),  Average  (A),  Hard  (H),  Very  Hard  (VH) 


Choices 

VE(5) 

E(4) 

A  (3) 


Count 

1 

4 

1 
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H(2) 

VH(1) 


0 

0 


Statistics 

Mean  E(4. 00) 

STD  0.63 


8.  If  you  encountered  any  errors,  recovering  from  the  errors  was: 

Very  Easy  (VE),  Easy  (E),  Average  (A),  Hard  (H),  Very  Hard  (VH) 


Choices 

VE(5) 

E(4) 

A  (3) 
H(2) 

mv 


Count 

0 

3 

3 

0 

0 


Statistics 

Mean  E(3.50) 

STD  0.55 


Tool  Ease  of  Use 


9.  Learning  to  operate  the  Process  Modeler  tool  was  easy  for  me. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A(4) 

N(3) 

D(2) 

SD(1) 


Count 

2 

4 

0 

0 

0 


Statistics 

Mean  A(4.33) 

STD  0.52 


10.  I  found  it  easy  to  get  the  Process  Modeler  tool  to  do  what  I  wanted  it  to  do. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 
N(3) 
D(2) 


Count 

0 

6 

0 

0 
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SD(1) 


0 


Statistics 

Mean  A(4.00) 

STD  0.00 

11.  My  interactions  with  the  Process  Modeler  tool  were  clear  and  understandable. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 

Count 
0 
6 
0 
0 
0 


Choices 

SA(5) 

A(4) 

N(3) 

D(2) 

SD(1) 


Statistics 

Mean  A(4.00) 

STD  0.00 


12.  I  found  the  Process  Modeler  tool  flexible  to  interact  with. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 

Choices 
SA(5) 

A  (4) 

N(3) 

D(2) 

SD(1) 

Statistics 

Mean  A  (4. 00) 

STD  0.63 


Count 

1 

4 

1 

0 

0 


13.  It  was  easy  for  me  to  become  skillful  at  using  the  Process  Modeler  tool. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 
N(3) 
D(2) 
SD(1) 


Count 

1 

5 

0 

0 

0 


Statistics 
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Mean 

STD 


4(4.17) 

0.41 


14.  Interacting  with  the  Process  Modeler  tool  did  not  require  a  lot  of  mental  effort. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 
N(3) 
D(2) 
SD(1) 


Count 

1 

4 

1 

0 

0 


Statistics 

Mean  A  (4. 00) 

STD  0.63 


15.  I  found  the  Process  Modeler  tool  easy  to  use. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 

m 

D(2) 

SD(1) 


Count 

1 

5 

0 

0 

0 


Statistics 

Mean  A(4.17) 

STD  0.41 


16.  What  changes  would  you  recommend  to  improve  the  ease  of  use  of  the  Process 
Modeler  tool?  (Open-Ended) 

1.  Improve  the  disappearance  and  reappearance  of  the  Process  Modeler  every  time 
a  change  is  made  so  that  recovery  brings  you  back  to  where  you  had  highlighted 
and  not  at  the  top  of  the  modeler  every  time. 

2.  none  at  this  point 

3.  In  the  process  model  we  used,  the  blinking  screen  whenever  a  change  was 
made  was  disturbing  and  disruptive.  Also  whenever  a  change  came  through,  the 
drop  down  chart  returned  to  the  top  line  even  though  I  was  working  on  a  separate 
line  entry. 

Overall  Assessment  of  the  Tool 
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17.  What  did  you  like  least  about  the  Process  Modeler  tool?  (Open-Ended) 

1 .  See  number  1 6 

2.  stated  in  earlier  comment 

3.  The  screen  resetting  after  other  user  inputs 

4.  Lack  of  edit  capability  (copy/cut  paste). 

Constant  jumping  of  fields  during  group  activity. 

5.  See  previous  comments 

18.  What  did  you  like  best  about  the  Process  Modeler  tool?  (Open-Ended) 

1.  it's  ease  of  use 

2.  Anonymity 

3.  Provides  clear  display  of  entire  process  for  objective  analysis. 

4.  Fun  and  easy  to  work  with.  Just  needs  a  few  bugs  worked  out. 

19.  If  you  could  change  only  one  thing  in  the  Process  Modeler  tool,  what  would  you 
tell  the  designers  to  change?  (Open-Ended) 

1 .  give  the  capability  to  make  multiple  selections 

2.  See  17 

3.  Reconsider  the  limit  of  40  characters. 

4.  Stop  interference  with  users  screen  during  operation  and  inputs  by  other  users. 


AFTO  107  Process  Model  Quality 


20.  The  overall  quality  of  the  AFTO  107  process  model  developed  was: 

Excellent  (E),  Very  Good  (VG),  Good  (G),  Fair  (F),  Poor  (P) 


Choices 

E(5) 

VG(4) 

G(3) 

F(2) 

m 


Count 

2 

2 

2 

0 

0 


Statistics 

Mean  VG(4.00) 

STD  0.89 

I 

21.  Personnel  involved  in  the  107  Process  could  easily  understand  the  meaning  of 
the  process  model  developed  with  a  minimum  amount  of  explanation. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 


Count 
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SA(5)  1 

A(4)  5 

N(3)  0 

D(2)  0 

SD(1)  0 


Statistics 

Mean  A(4.17) 

STD  0.41 


22.  The  process  model  developed  was: 

Completely  Correct  (CC),  Mostly  Correct  (MC),  Average  (A),  Somewhat  Incorrect  (SI), 
Mostly  Incorrect  (MI) 


Choices 

CC(5) 

MC(4) 

A  (3) 

SI(2) 

MI(1) 


Count 

0 

6 

0 

0 

0 


Statistics 

Mean  MC(4.00) 

STD  0.00 


23.  The  process  model  developed  was: 

Very  Complete  (VC),  Mostly  Complete  (MC),  Average  (A),  Somewhat  Incomplete  (SI), 
Very  Incomplete  (VI) 


Choices 

VC(5) 

MC(4) 

A  (3) 

SI(2) 

VI(1) 


Count 

2 

3 

1 

0 

0 


Statistics 

Mean  MC(4.17) 

STD  0.75 


24.  The  process  descriptions  developed  were: 

Very  Clear  (VC),  Mostly  Clear  (MC),  Average  (A),  Somewhat  Vague  (SV),  Very  Vague 

(W) 


Choices 


Count 
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Choices 

SA(5) 

A  (4) 

N(3) 

D(2) 

SD(1) 

Statistics 

Mean 

STD 


Count 

4 

1 

0 

1 

0 


A(4.33) 

1.21 


28.  The  meeting  approach  allowed  me  to  everything  I  needed  to  do  to  define  the 
AFTO  107  process. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 

N(3) 

D(2) 

SD(1) 

Statistics 

Mean 

STD 


Count 

1 

4 

1 

0 

0 


A(4. 00) 
0.63 


29.  How  could  the  approach  followed  in  the  meeting  to  create/validate  the  AFTO 
107  process  be  improved?  (Open-Ended) 

1.  Disappointed  in  that  the  suggestion  to  review  other  bases  -107  process  only 
provided  a  list  of  apparent  bias  personal  comments  rather  than  the  expected 
intended  model  process  flow  chart  as  first  formulated  and  reviewed  at/by 
Mountain  Home  AFB,  ID. 

2.  Need  to  get  all  the  players  involved  in  this  process. 

All  the  MAJCOMS  need  to  represented  as  well  as  Wing  Schedulers. 

3.  Author  of  TO  00-15-107  should  have  been  in  attendance  to  explain/defend  the 
current  TO. 

4.  Again,  have  the  proper  level  of  authority/decision  makers  present....i.e.  Air 
Staff  policy  makers. 

30.  How  satisfied  were  you  with  the  overall  meeting  approach? 

Very  Satisfied  (VS),  Mostly  Satisfied  (MS),  Average  (A),  Somewhat  Unsatisfied  (SU), 
Very  Unsatisfied  (VU) 


Choices 


Count 
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VS(5) 

MS (4) 

A  (3) 
SU(2) 

VU(1) 

Statistics 

Mean 

STD 


4 

2 

0 

0 

0 


VS(4.67) 

0.52 


Demographics 

31.  How  many  years  have  you  been  working  for  the  military  (combined  active  duty 
and  civilian  time)?  (Assign  a  number) 

Value  Count 


20  1 

22  1 

23  3 

32  1 


Statistics 

Mean  23.83 

STD  4.17 


32.  How  many  years  have  you  been  working  with  the  AFTO  107  Process?  (Assign  a 
number) 


Value 

1 

4 

11 

15 

22 

23 


Count 

1 

1 

1 

1 

1 

1 


12.67 
9.09 

33.  How  often  do  you  use  a  computer? 

Select  the  appropriate  response 

[  6  ]  Several  times  each  day 
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[  0  ]  Once  a  day 

[  0  ]  Several  times  each  week 

[  0  ]  Once  a  week 

[  0  ]  Rarely 


34.  How  would  you  rate  your  expertise  with  use  of  Internet  Browsers? 

Excellent  (E),  Very  Good  (VG),  Good  (G),  Fair  (F),  Poor  (P) 


Choices 

E(5) 

VG(4) 

G(3) 

F(2) 

m 

Statistics 

Mean 

STD 


Count 

0 

2 

3 

1 

0 


G(3. 1 7) 
0.75 


35.  Before  this  meeting,  how  many  times  had  you  used  GroupSystems? 

Select  the  appropriate  response 


[  0  ]  Many  times 

[  2  ]  2  -3  times 

[  1  ]  1  time 

[  3  ]  Never 


36.  Before  this  meeting,  how  many  times  had  you  developed  a  process,  activity,  or 
similar  type  model? 

[  1  ]  Many  times 

[  2  ]  2  -3  times 

[2  ]  1  time 

[  1  ]  Never 
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Session  Name: 
Report  Generated : 


Process  Tree  Hierarchy 

Process  AFTO  107  Requests  for  Tech  Assist 

•  Determine  Repair  Needs 

•  Research  Repair  Requirements 

•  Research  Repair  in  Technical  Orders 

•  Review  Other  Related  Manuals 

•  Contact  Other  Bases  for  Similar  Problems 

•  Review  Maintenance  History 

•  Determine  if  Capability  is  at  Base  Level 

•  Determine  Parts  Availability 

•  Determine  Equipment  Availability 

•  Determine  Personnel  Availability 

•  Determine  Funds  Availability 

•  Contact  Depot  for  Special  Assistance 

•  Repair  Locallv/Return  to  Operation 

•  Prepare  &  Submit  107  Request 

•  Initiate  107  Checklist 

•  Produce  107  Narr  at  Work  Center  Level 

•  Describe  Problem 

•  Create/Collect  Visual  Aids 

•  Collect  Other  Supporting  Material 

•  Prepare  Specific  Depot  Repair  Request 

•  Review  107  Narrative 

•  Review  Narrative  for  Completeness 

•  Validate  Local  Resources 

•  Determine  Fleet  Implications 

•  Complete  107  &  Submit  Rea  for  Assistance 

•  Review  107  Narr/Checklist  Completeness 

•  Prepare  107  for  Transmission 

•  Submit  107  to  MAJCOM/Denot 

•  Verify  with  MAJCOM/Depot  Receipt  of  107 

•  Change  Aircraft/Equipment  Possession 

•  Process  107  Request  at  MAJCOM 

•  Receive  107  at  MAJCOM 
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•  Evaluate  107  Request 

•  Validate  107 

•  Research  107 

•  Request  Additional  Information  from  Unit 

•  Certify  funding  is  available  for  repair 

•  Cost  estimate  pre-certification 

•  Review  Cost  Prohibitive  Estimates 

•  Execute  107  Disposition 

•  Forward  107  Certification 

•  Forward  107  Disapproval 

•  Process  MAJCQM  Response  at  Wing 

•  Provide  Additional  Information 

•  Review  MAJCQM  Approval/Disapproval 

•  Submit  Msg  to  reflect  Possession  Change 

•  Process  107  Request  at  Depot 

•  Receive  107  Request  at  Depot 

•  Log-in  107 

•  Send  Copy  of  107  to  Engineering 

•  Evaluate  and  Make  Disposition  of  107 

•  Assign  Priority  to  107 

•  Assign  107  to  Engineer 

•  Log-in  to  Tracking  Database 

•  Prepare  Disposition 

•  Review  107  Request 

•  Review  Drawings  in  Data  Repository/TOs 

•  Request  Additional  Info  from  Field 

•  Develop  Repair 

•  Approve  Disposition 

•  Receive  MAJCQM  Cert/Disapproval 
»  Execute  Disposition  of  107 

•  Draft/Send  Repair  Disp  Message  to  Unit 

•  Prepare  Costing  &  Pers  Details  for  DFT 

•  Prepare  206  for  DFT  Deployment 

•  Request  Applicable  SOR 

•  Prepare  and  Ship  Tooling 

•  Deploy  DFT  if  applicable 
Process  Depot  Response  at  Wing 

•  Notify  Work  Center  of  Depot  Response 

•  Lose  Possession 

•  Provide  Additional  Information 

•  Follow  Depot  Instructions 

•  Order  Parts  and/or  Equipment  as  Required 
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•  Research  Required  Parts  and  Equipment 

•  Prepare  &  Submit  Order  for  Parts  &  Equip 

•  Receive  Ordered  Parts  and  Equipment 

•  Follow  up  on  Backordered  Parts/  Equip 

•  Notify  Depot  of  Parts/Equipment  Receipt 
•  Repair  Item/Return  to  Operation 

•  Complete  Temp  Fix  &  Send  Item  to  Depot 

•  Coord  Depot  Field  Team  Repair  Efforts 

•  Follow  Depot  Guidance  for  Local  Repair 

•  Continue  Operation  of  Item 

•  Permanently  Remove  from  Service 

•  Prepare  &  Submit  Supp  107  As  Read 

•  Verify  107  Completion 

•  Inspect  Repair  by  OA 

•  Review  Repair  Documentation 

•  Notify  Wing  P&S  of  Completion 

•  Notify  MAJCOM/Depot  of  Completion 

•  Submit  Msg  to  reflect  Possession  Change 


Process:  Process  AFTO  107  Requests  for  Tech  Assist 


Description 

2.  Procedures  for  processing  of  an  AFTO  107  request  for  technical  assistance  on 
aircraft/equipment/system  that  are  in  need  of  repair. 

Trigger 

2.  Aircraft  Failure  or  Problem 

Problems/Solutions 

3.  Problem:  You  still  need  to  wait  for  the  engineer  to  research  the  problem. 

4.  Problem:  Cannot  add  it  to  the  Maintainers  Conference-  already  to  much  going  on 
at  this  conference 

5.  Solution:  Instead  of  an  additional  conference  add  a  side  meeting  at  an  existing 
conference  such  as  the  Maintainers  conference  to  discuss  107s. 

6.  Problem:  The  whole  AFTO  107  submission  process  is  too  slow  and  time 
consuming.  There  is  a  valid  need  to  folly  automate  the  system  to  provide 
management  with  real  time,  quick  decision  making  capability.  Loop  the 
unit/MAJCOM/Depot  into  a  real  time  system. 

7.  Solution:  Air  Staff  initiate  and  fond  advanced,  state-of-the-art,  real  time  AFTO 
107  submission/evaluation/validation/approval/disapproval  process. 

8.  Problem:  Different  MAJCOMs/Depots  doing  their  own  repair  initiatives,  etc. 

9.  Solution:  Establish  an  annual  107  Worldwide  conference.  Conference  will  give 
the  added  benefit  of  face  to  face  contact  additional  time  spent  with  experts  in  the 
field  for  exchange  of  ideas  and  experiences  to  take  back  to  home  bases. 
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Overview 

1 .  Parent  Process :  Root 

2.  Number  of  Children:  12 
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Process:  Determine  Repair  Needs 


Description 

2.  Determine  the  specific  repair  needs  by  using  all  available  resources,  to  include 
CFT  if  available. 

3.  Consult  Air  Force  Engineers  Technical  Service  (AFETS)  personnel  for  additional 
expertise. 

Trigger 

2.  Aircraft/Equipment/System  Failure  or  Problem 
Overview 

3.  Parent  Process:  Process  AFTO  1 07  Requests  for  Tech  Assist 

4.  Number  of  Children:  4 
Actors 

1.  QA  Personnel  - 

2.  Maintenance  Personnel  - 


Process:  Research  Repair  Requirements 


Description 

4.  Check  specific  aircraft  Technical  Orders  and  other  related  materials  to  determine 
repair  procedures  and  level  of  repair  (local  or  depot)  allowed. 

Trigger 

2.  Aircraft/Equipment/System  Failure  or  Problem 

Overview 

2.  Parent  Process:  Determine  Repair  Needs 

3.  Number  of  Children:  7 
Actors 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

5.  QA  Personnel  - 


Process:  Research  Repair  in  Technical  Orders 


Description 

1 .  Review  applicable  TO  to  verify  the  type,  procedures,  and  authorized  level  of 
repairs  required. 

Problems/Solutions 

4.  Problem:  Specific  area  in  question  is  not  in  T.O. 

5.  Solution:  Contact  DEPOT  on  Voice  or  E-Mail  for  Assistance  in  locating  Info,  or 
contact  AFETS  to  see  if  engineering  drawings  are  available  locally 
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Overview 

2.  Parent  Process:  Research  Repair  Requirements 

3.  Number  of  Children:  0 
Actors 

3.  Maintenance  Personnel  - 

4.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acfit/equip/systems 

5.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

6.  QA  Personnel  - 


Process:  Review  Other  Related  Manuals 


Description 

1 .  Check  message  files,  drawings,  manufacturer  manuals,  bulletins,  procedure  TO, 
and  Time  Compliance  TOs  for  assistance  in  determining  repair  procedures. 

Overview 

5.  Parent  Process:  Research  Repair  Requirements 

6.  Number  of  Children:  0 
Actors 

2.  Maintenance  Personnel  - 

3.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

5.  QA  Personnel  - 


Process:  Contact  Other  Bases  for  Similar  Problems 


Description 

3.  Contact  other  Air  Force  bases,  Department  of  Defense,  and  government  services 
with  same  aircraft/equipment  that  may  have  had  similar  problems  and  request 
documentation,  when  available. 

Problems/Solutions 

1 .  Solution:  B-l  tech  services  maintains  an  on-line,  web  based  database  of 
maintenance  assist  requests  and  solutions.  It  is  available  for  review  by  all  B-l 
units.  Negates  the  need  to  generate  another  product,  and  ensures  technicians  with 
a  need  for  the  information  can  access  it,  vice  a  crosstell  that  may  or  may  not  get 
disseminated  to  the  appropriate  work  centers 

2.  Solution:  Encourage  all  units  to  send  out  cross  tells  to  share  repair  ideas  and 
initiatives 

3.  Problem:  If  another  base  has  had  the  same  problem  and  already  have  performed  a 
fix  we  can  not  use  it  until  we  run  the  process  over  again. 
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4.  Solution:  Create  a  standardized  library  of  repair  initiatives  on  one  web  site, 

accessible  to  all  wings  (by  type  aircraft).  This  approach  would  have  the  follow-on 
benefit  of  capturing  data  for  possible  technical  order  changes,  or 
reliability/maintainability  modifications.  Also  worldwide  availability  of 
equipment  could  be  identified  at  any  time  around  the  world. 

Overview 

4.  Parent  Process:  Research  Repair  Requirements 

5.  Number  of  Children:  0 
Actors 

2.  Maintenance  Personnel  - 

3.  Maintenance  Personnel  from  other  bases  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Review  Maintenance  History 


Description 

3 .  Review  maintenance  history  using  CAMS,  Aircraft  forms  (781  's),  other  1 07's,  and 
shop  maintenance  history  for  past  repairs  of  a  similar  nature. 

Problems/Solutions 

1 .  Problem:  Current  data  bases  (CAMS)  are  not  user  friendly  which  causes  errors  or 
blanks  in  maintenance  history. 

Overview 

5.  Parent  Process:  Research  Repair  Requirements 

6.  Number  of  Children:  0 
Actors 

2.  Maintenance  Personnel  - 

3.  Wing  P&S  Personnel  - 


Process:  Determine  if  Capability  is  at  Base  Level 


Description 

3.  CETS  -  Contract  Engineering  Technical  Services 

4.  Check  specific  aircraft  TO's  and  other  related  items,  verify  whether  or  not  the 
owning  work  center  has  equipment  and  knowledge  to  complete  repair.  This  would 
also  include  consulting  local  subject  matter  experts  AFETS/CETS  and  on-site 
CFT,  if  available. 

Overview 

1 .  Parent  Process:  Determine  Repair  Needs 

2.  Number  of  Children:  3 
Actors 

2.  Maintenance  Personnel  - 
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3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Determine  Parts  Availability 


Description 

3.  Using  the  necessary  TO's,  determine  which  parts  are  needed  for  the  repair. 
Determine  if  the  needed  parts  are  available  at  the  owning  work  center  or 
elsewhere  on  base.  If  parts  are  not  available,  determine  if  they  are  procurable  or 
non-procurable. 

Resources 

3.  Dollars  to  procure/ship  parts  can  be  a  problem,  especially  at  end  FY. 

Problems/Solutions 

1 .  Problem:  A  lot  of  times  we  need  Depot  to  tell  us  what  we  will  require.  We  have  a 
lot  of  calls  being  made  back  and  forth  and  a  lot  of  telephone  messages  being  left. 

Overview 

3.  Parent  Process:  Determine  if  Capability  is  at  Base  Level 

4.  Number  of  Children:  0 

Actors 

2.  Maintenance  Personnel  - 

3.  Supply  Personnel  - 


Process:  Determine  Equipment  Availability 


Description 

3.  Also,  may  want  to  check  with  other  bases  for  equipment  availability. 

4.  Verify  if  special  equipment  is  needed  using  TO's  (see  step  A1 .2).  If  equipment  is 
needed,  does  the  owning  work  center  have  the  equipment?  If  not,  does  anyone  on 
base?  If  not,  is  it  procurable  or  non-procurable? 

Resources 

1 .  Dollars  to  procure/ship  equipment  can  be  a  problem,  especially  at  end  FY. 

Overview 

3.  Parent  Process:  Determine  if  Capability  is  at  Base  Level 

4.  Number  of  Children:  0 

Actors 

2.  Maintenance  Personnel  - 

3.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 
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Process:  Determine  Personnel  Availability 

Description 

2.  Determine  if  the  performing  work  center  has  skilled  technicians  available  to 
accomplish  the  required  task. 

Problems/Solutions 

3.  Solution:  Include  all  shortfalls  in  the  107  or  in  the  dialogue  with  engineer  so  that 
proper  disposition  as  to  whether  a  DFT  or  field  repair  is  allowed. 

4.  Problem:  Not  all  bases  have  technicians  trained  on  required  repairs 

5.  Solution:  When  training  is  being  conducted  at  one  base,  Contact  other  bases  with 
same  equipment  to  see  if  they  want  to  send  technicians  to  get  training  Problem: 
Some  bases  have  trained  personal  and  equipment  deployed  so  it  leaves  home 
station  or  deployed  locations  short 

Overview 

1 .  Parent  Process:  Determine  if  Capability  is  at  Base  Level 
,  2.  Number  of  Children:  0 

Actors 

3.  Maintenance  Personnel - 

4.  QA  Personnel  - 

Process:  Determine  Funds  Availability 


Description 

2.  The  funds  needed  to  repair  the  item  or  system 
Overview 

2.  Parent  Process:  Determine  if  Capability  is  at  Base  Level 

3.  Number  of  Children:  0 


Process:  Contact  Depot  for  Special  Assistance 


Description 

3 .  Note:  If  you  do  this  include  the  person  contacted  in  the  107  request. 

4.  Contact  Depot  Equipment  Specialists/Engineers  for  any  unclear  areas  in  the  TO's 
or  to  determine  if  Depot  will  allow  the  owning  work  center  to  accomplish  the 
repair. 

Problems/Solutions 

1 .  Problem:  There  are  sometimes  several  personal  attempting  to  contact  the  Depot 
for  information  on  the  same  malfunction.  This  can  cause  confusion  both  at  the 
Depot  and  Field  level. 

2.  Solution:  This  problem  is  eliminated  when  a  wing  focal  point  (i.e.,  QA)  is 
identified  as  the  single  point  within  a  wing  for  107  requests  Problem:  Having  a 
single  point  of  contact  sometimes  leave  less  knowing  people  talking  about  the 
problem 
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3.  Solution:  Contacts  should  be  limited  to  i.e.,  AFETS,QA  or  FLT/SHOP  CHIEF'S 

4.  Solution:  See  proposals  under  "Contact  Other  Bases  for  Similar  Problems"  node 
above  to  capture  information 

5.  Problem:  Having  one  point  of  contact  sometimes  leaves  a  less  experience  person 
talking  to  depot 

6.  Problem:  Contact,  details,  direction,  etc.  not  always  captured  by 
individuals/shops/units  make  first  contact  which  is  lost  to  management  as  possible 
use  in  decision  metrics. 

Overview 

4.  Parent  Process:  Determine  Repair  Needs 

5.  Number  of  Children:  0 
Actors 

2.  Maintenance  Personnel - 

3.  QA  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Repair  Locally/Return  to  Operation 


Description 

2.  After  a  review  of  the  local  repair  capability,  it  is  determined  that  the 
aircraft/equipment/system  can  be  fixed  on  site  by  local  mechanics/engineers  or  it 
is  determined  that  the  aircraft/equipment/system  does  not  need  to  be  repaired  at 
this  time  and  can  be  returned  to  operations. 

Trigger 

3.  Decision  to  Repair  Locally 

Problems/Solutions 

1 .  Problem:  Many  times  local  repair  is  not  considered  because  Wing  lacks  a  special 
tool  or  jig.  Solution:  Giving  the  Wings  access  to  these  tools  would  result  in  more 
local  repairs. 

2.  Solution:  Wings  can  approach  Companies,  i.e.  Boeing,  and/or  specific  depots,  i.e. 
WR-ALC,  to  inquire  about  purchasing  or  manufacturing  their  own  "special 
tooling".  Drawings  and/or  specific  information  can  be  obtained  through  these 
services. 

3.  Solution:  Contact  other  bases  to  determine  if  tooling  or  equipment  is  available  for 
use 

Overview 

5.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

6.  Number  of  Children:  0 

Actors 

3.  Maintenance  Personnel  - 

4.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/sy  stems 
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5.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

6.  QA  Personnel  - 


Process:  Prepare  &  Submit  107  Request 

Description 

2.  107  Request  may  be  a  Request  for  Technical  Assistance  or  Maintenance  Support 
Request.  Tech  Asst  request  does  not  require  MAJCOM  validation  (unless 
otherwise  directed  by  MAJCOM)  and  may  be  EMailed  directly  to  depot.  If  the 
Tech  Asst  request  is  disapproved  by  the  depot,  then  a  107  Maintenance  Support 
Request  must  be  initiated  and  submitted  to  the  MAJCOM. 

3 .  Wing  level  coordinated  effort  with  QA  product  improvement,  Wing  P&S,  owning 
unit/backshop  maintenance  personnel  and  AFETS.  QA's  product  improvement 
section  should  be  the  lead  for  preparing  and  submitting  the  AFTO  107  due  to  their 
technical  background.  Wing  P&S  should  have  secondary  responsibility  to  provide 
the  administrative  checks  and  balances  and  proper  notifications  required. 

4.  Responsibility  for  submission  of  AFTO  107s  varies  from  base  to  base  and  by 
MAJCOM.  For  example,  Tyndall  AFB  has  a  Depot  Liaison  who  is  not  part  of 
Wing  P&S  or  QA.  The  Depot  Liaison  processes  and  submits  all  107s. 

Trigger 

3 .  Decision  to  Request  Depot  Assistance 

Problems/Solutions 

1 .  Problem:  The  MAJCOM/Depot  field  107's  from  many  bases,  How  would  you 
coordinate  video  conferences  to  satisfy  all  customers.  I'm  sure  MH  would  not 
want  to  wait  for  a  scheduled  conference  to  discuss  a  repair.  This  problem  is 
exacerbated  by  time  differences  between  depots  and  operating  locations  around 
the  globe 

2.  Problem:  Focal  point  for  release  of  depot  maintenance  assistance  request  is  not 
standardized. 

3.  Possible  solution:  Supplement  TO  00-25-107  with  MAJCOM  supplements.  (This 
approach  was  adopted  as  an  action  item  by  the  recent  ACC  LOCAT  that  visited 
Mountain  Home  AFB) 

4.  Problem:  Air  Staff  needs  to  standardize  at  wing  level  who  is  technically 
responsible/capable  of  providing  the  most  descriptively  thorough  107.  Opinion  of 
this  working  group  is  that  QA  is  best  choice  and  not  P&S. 

5.  Problem:  107  submission  process  is  slow.... 

6.  Solution:  Need  to  develop  an  on-line,  real-time  video  conferencing  capability  to 
join  unit/MAJCOM/Depot  decision  makers  for  fast  disposition. 

7.  Solution:  The  wings  recognize  this  limitation,  we  are  asking  for  the  WHOLE 
process  to  be  quicker. 

Overview 

5.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

6.  Number  of  Children:  4 
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Actors 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 

4.  Maintenance  Personnel  - 


Process:  Initiate  107  Checklist 


Description 

2.  Follow  step  by  step  instructions  on  107  Request  Checklist/Worksheet  as 
applicable  (see  for  example,  MHAFBI 21-172  Attachment  2  checklist). 

Problems/Solutions 

3.  Problem:  The  Depot  does  not  know  all  the  units  needs,  maybe  the  checklist 
should  be  approved  by  the  MAJCOM. 

4.  Problem:  Not  all  wings  use  checklist/sheet  when  processing  107s  causing  less 
than  optimum  input/concems/information  to  MAJCOMs/depot. 

5.  Solution:  Have  all  bases  use  standard  check  list  approved  by  DEPOT'S  with  the 
info  needed  by  depot,  after  base  can  add  to  check  list  as  needed 

6.  Solution:  A  checklist  should  be  established  and  disseminated  to  all  wings  for 
inputs  to  be  standardized 

Overview 

1.  Parent  Process:  Prepare  &  Submit  107  Request 

2.  Number  of  Children:  0 

Actors 

3.  QA  Personnel  - 


Process:  Produce  107  Narr  at  Work  Center  Level 


Description 

2.  Create  a  narrative  for  the  1 07  request  form.  This  will  be  a  very  technically 
detailed  narrative  of  the  discrepancy.  Prescribed  format  in  T.O.  00-25-107  will  be 
used  as  a  guideline. 

Trigger 

3 .  Decision  to  request  Depot  repair  assistance 
Overview 

1 .  Parent  Process:  Prepare  &  Submit  1 07  Request 

2.  Number  of  Children:  3 
Actors 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 
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Process:  Describe  Problem 


Description 

3.  List  detailed  description  and  location  of  the  discrepancy,  describe  the 

unsatisfactory  condition,  what  has  been  done  to  try  to  correct  it,  and  list  the  items 
that  are  damaged,  missing,  or  needing  repair. 

Problems/Solutions 

3.  Problem:  Engineer  may  not  understand  what  writer  of  narrative  is  trying  to 
explain. 

4.  Solution:  Writer  of  narrative  contact  DEPOT  by  voice  and  talk  it  out  to  until  both 
parties  are  on  the  same  page. 

5.  Solution:  That  is  what  the  real  time  capability  would  allow  us  to  do . eliminate 

all  the  back  and  forth,  waiting  for  a  response  via  message  traffic  or  e-mail.... we 
would  be  able  to  see  each  representative,  the  pictures,  drawings,  etc.  while  on 
line. 

Overview 

1 .  Parent  Process:  Produce  107  Narr  at  Work  Center  Level 

2.  Number  of  Children:  0 

Actors 

4.  Maintenance  Personnel  - 

5.  Q A  Personnel  - 

6.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Create/Collect  Visual  Aids 


Description 

3.  Process  Name:  Create  Drawings,  Diagrams,  &  Other  Items  Requested  by  Depot 

4.  Take  measurements  of  damage  or  defects  such  as  gaps,  tears  and  holes.  Include 
this  on  a  drawings  and  list  allowable  limits  from  TO's.  Take  pictures  (digital 
imaging)  and  create  other  visual  aids  that  make  the  problem  clearer. 

Problems/Solutions 

3.  Solution:  E-mail  is  currently  being  used  to  forward  digital  pictures  of  damage. 

4.  Solution:  ACC  already  funds  the  B-l's  for  their  ETAR  program  with  new 

computers,  printers,  digital  cameras  and  software  to  support  it . what  about  the 

other  flying  units  specifically  F-15's? 

5.  Problem:  Due  to  current  107  submittal  process,  new  technology  is  not  always 
used  to  transmit  necessary  information  for  use  by  depots.. ..i.e.  digital  camera 
shots. 

6.  Solution:  As  part  of  Air  Staff  initiative  and  funding,  each  wing  would  receive 
necessary  computers,  digital  cameras,  training,  etc.  to  allow  for  this  capability. 

Overview 

1 .  Parent  Process:  Produce  1 07  Narr  at  Work  Center  Level 

2.  Number  of  Children:  0 
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Actors 

5.  Maintenance  Personnel  - 

6.  QA  Personnel  - 

7.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Collect  Other  Supporting  Material 

Description 

2.  Include  previous  engineering  dispositions  authorizing  permanent/temporary 
repairs  for  the  system  or  adjacent  components/structure. 

Overview 

2.  Parent  Process:  Produce  107  Narr  at  Work  Center  Level 

3.  Number  of  Children:  0 


Process:  Prepare  Specific  Depot  Repair  Request 


Description 

3.  List  what  you  expect  Depot  to  provide  you,  ask  for  guidance  on  level  of  repair, 
ask  them  to  determine  whether  system  is  still  usable,  and  for  any  temporary  repair 
procedures.  Include  information  concerning  any  upcoming  deployments,  phase 
inspections,  or  PDM  input. 

4.  Note:  Consider  recommending  change  to  T.O.  00-25-107  to  require  including  info 
on  upcoming  deployments,  phase  inspections,  or  PDM  input. 

Problems/Solutions 

1 .  Problem:  Base  may  not  have  capability  to  do  repair  as  depot  specified. 

2.  Solution:  When  performing  work  center  contacts  depot,  talk  with  engineer  as  to 
how  work  is  to  be  accomplished  and  any  short  falls  you  may  have 

Overview 

5.  Parent  Process:  Produce  107  Narr  at  Work  Center  Level 

6.  Number  of  Children:  0 

Actors 

2.  Maintenance  Personnel  - 

3.  QA  Personnel  - 

4.  Wing  P&S  Personnel  - 


Process:  Review  107  Narrative 


Description 

3.  Review  107  narrative  with  owning  and  performing  work  centers  for  completeness 
and  initiate  the  local  107  checklist/worksheet. 
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Trigger 

1 .  Receipt  of  1 07  Narrative  from  work  center  or  Request  for  additional  information 

Problems/Solutions 

4.  Problem:  TO  00-25-107  gives  a  specific  format  for  requesting  O&I  level 
maintenance  assistance,  para  6.2.  It  does  not  give  a  format  for  requesting  depot 
level  maintenance  assistance. 

5.  Possible  solution:  Submit  AFTO  FORM  22  to  insert  proper  format  for  both  types 
of  maintenance  requests.  (See  discussions  regarding  standardization/use  of  a 
common  107  checklist  in  other  nodes) 

Overview 

2.  Parent  Process:  Prepare  &  Submit  107  Request 

3.  Number  of  Children:  5 

Actors 

3.  QA  Personnel  - 

4.  Maintenance  Personnel  - 

5.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Review  Narrative  for  Completeness 


Description 

1 .  Review  narrative  content  and  supporting  materials  for  accuracy  and  ensure 
description  of  the  problem  is  complete.  Make  sure  all  supporting  documents  are 
included. 

Overview 

4.  Parent  Process:  Review  107  Narrative 

5.  Number  of  Children:  0 
Actors 

2.  QA  Personnel  - 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Validate  Local  Resources 


Description  / 

3.  Identify  which  equipment  and  parts  are  not  available  at  the  work  centers  needed 
to  complete  the  task.  This  information  should  be  included  in  the  107  Request. 

Problems/Solutions 

1 .  Problem:  Base  may  have  short  falls  in  material,  tooling  or  other  areas. 

2.  Solution:  Contact  other  bases  to  see  if  items  can  be  used/  contact  local  businesses 
to  see  if  items  can  be  locally  procured. 
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Overview 

6.  Parent  Process:  Review  107  Narrative 

7.  Number  of  Children:  0 
Actors 

2.  QA  Personnel  - 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Determine  Fleet  Implications 


Description 

3.  Review  seriousness  of  the  problem,  and  determine  if  other  aircraft/equipment  may 
be  affected,  or  have  the  same  discrepancy. 

Problems/Solutions 

1 .  Problem:  Lack  of  methodology/ system  to  automatically  perform  this  function. 

2.  Solution:  As  part  of  the  Air  Staff  initiative,  the  program  would  automatically  alert 
via  the  systems  connections  to  all  other  wings  of  the  fact  there  is  a  problem  and 
possible  need  for  a  one  time  inspection. 

3.  OK 
Overview 

2.  Parent  Process:  Review  107  Narrative 

3.  Number  of  Children:  0 
Actors 

3.  QA  Personnel  - 

4.  Maintenance  Personnel  - 

5.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 


Process:  Complete  107  &  Submit  Req  for  Assistance 


Description 

2.  Process  Name:  Complete  107  and  Submit  Request  for  Assistance 

3.  Ensure  1 07  is  completed  and  submitted  in  the  correct  format  to 
MAJCOM/DEPOT. 

Trigger 

3.  Receipt  of  validated  107  narrative 

Problems/Solutions 

1 .  Solution:  Develop  a  Web-based  form  that  asks  for  all  of  the  required  information, 
allows  for  drawings  and  digital  pictures  to  be  attached,  and  can  be  submitted  to 
the  appropriate  agencies  by  clicking  a  button  when  finished. 
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2.  (Again,  refer  to  on-line  process  used  for  the  B-l  program.  It  has  mandatory  data 
edits,  and  authorizations  that  prohibit  transmission  from  base  and  MAJCOM  until 
'approval'  authority  validates  the  requirement. 

3.  Problem:  Air  Staff  needs  to  develop  new  program  for  107  submittal  based  on 
computer  program  that  requires  all  information  be  addressed  before  107  can  be 
submitted. 

Overview 

3.  Parent  Process:  Prepare  &  Submit  1 07  Request 

4.  Number  of  Children:  3 
Actors 

3.  Wing  P&S  Personnel  - 

4.  QA  Personnel  - 


Process:  Review  107  Narr/Checklist  Completeness 


Description 

3.  Process  Name:  Review  107  Narrative  and  Checklist  for  Completeness 

4.  Check  107  request  form  for  completeness  and  accuracy.  Review  107  checklist  and 
all  supporting  materials  for  completeness. 

Problems/Solutions 

1.  Problem:  Para  7.1,  TO  00-25-107,  Format  for  submitting  maintenance  assistance, 
does  not  consider  PDM  input/deployment/phase  time  as  a  factor  in  determining 
economy  of  repair. 

2.  Possible  solution:  AFTO  FORM  22,  TO  00-25-107,  to  change  this  para  to  reflect 
these  considerations,  and  build  these  considerations  into  the  local  checklist/review 
process. 

Overview 

4.  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

5.  Number  of  Children:  0 

Actors 

4.  Maintenance  Personnel  - 

5.  QA  Personnel  - 

6.  Wing  P&S  Personnel  - 

7.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Prepare  107  for  Transmission 

Description 

3.  Include  in  the  107,  as  a  REF:  (reference)  listed  under  the  SUBJECT  title,  the 
name  of  any  engineer  that  you  have  been  in  contact  with. 

4.  Prepare  E-Mail  or  Make  Cover  Sheet  for  FAX  and  put  107  request  in  message 
format  using  special  computer  program  (Sarah  Lite)  IAW  T.O.  00-25-107. 
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5.  Note:  Need  to  explore  making  this  process  real-time.  As  an  interim  solution,  can 
an  Email  message  totally  replace  the  formal  Sarah  Lite  message? 

6.  Preferred  method  of  sending  request  to  MAJCOM  is  via  e-mail.  Reference:  Air 
Force  Instruction  (AFI)  33-12,  "Information  may  be  sent  between  offices  or 
individuals,  or  be  displayed  on  the  web.  The  Air  Force  goal  for  the  Internet  is  to 
provide  maximum  availability  at  acceptable  risk  levels  for  Air  Force  members 
needing  access  for  the  execution  of  official  business."  E-mail  transmission  allows 
for  use  of  digital  imaging  to  accompany  depot  maintenance  requests. 

Overview 

1.  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 
Actors 

2.  QA  Personnel  - 

3 .  Wing  P&S  Personnel  - 


Process:  Submit  107  to  MAJCOM/Depot 


Description 

4.  Occasionally,  107  requests  are  sent  directly  to  depot  without  going  through  proper 
channels.  Proper  Procedures  for  Requesting  Depot  Maintenance  Assistance  - 
Technical  assistance  requests  will  be  forwarded  directly  to  the  depot  unless 
directed  by  MAJCOM  -0&  I  Level  maintenance  requests  will  be  forwarded  to  the 
MAJCOM  for  certification  -Unprogrammed  depot  level  maintenance  requests  will 
be  submitted  through  the  MAJCOM  for  certification  Re:  T.O.  00-25-107,  para 
6.1, 6.2 ,6.3 

5.  Send  completed  107  and  supporting  materials  to  MAJCOM/Depot  via  FAX,  E- 
Mail,  or  Base  Communication  Center. 

6.  Preferred  method  of  sending  request  to  MAJCOM  is  via  e-mail 

Problems/Solutions 

3.  Problem:  When  requesting  Unprogrammed  depot  level  maintenance  assistance, 
the  requirement  to  use  a  message  is  unnecessary.  "Messaging"  requires  use  of 
SARA  LITE  which  has  always  been  awkward  and  time  consuming  to  use.  Current 
authorized  process  of  e-mail  "heads  up  copy",  followed  by  a  formal  message  is 
duplication  of  effort.  Use  of  e-mail  would  increase  the  speed  of  disposition  and 
provide  the  opportunity  to  exploit  the  benefit  of  digital  imaging. 

4.  Possible  solution:  AFTO  FORM  22  to  change  TO  00-25-107,  para  6.2,  to  allow  e- 
mail  transmission  of  request  in  format  specified  in  para  7  based  on  AFI  33-12. 

Overview 

1 .  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 

Actors 

3.  Q A  Personnel - 
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Process:  Verify  with  MAJCOM/Depot  Receipt  of  107 

Description 

3.  Contact  MAJCOM/Depot  via  Land  Line  or  other  means  to  ensure  they  received 
107. 

4.  Note:  If  EMail  was  used,  the  Return  Receipt  capability  will  automatically  provide 
this  functionality. 

Problems/Solutions 

3.  Problem:  Lack  of  automated  107  submission  negates  quick  feedback  loop  to 
verify  receipt. 

Overview 

1.  Parent  Process:  Complete  107  &  Submit  Req  for  Assistance 

2.  Number  of  Children:  0 
Actors 

3.  QA  Personnel  - 

4.  Wing  P&S  Personnel  - 


Process:  Change  Aircraft/Equipment  Possession 

Description 

2.  Also  must  notify  MOC/QA/Owning  Organization  of  change. 

3 .  Wing  P&S  submits  AFI 21-103  change  of  possession  purpose  identifier  message 
(e.g.,  BQ  -  waiting  AFMC  action/decision). 

Trigger 

2.  Notification  of  107  Submission 

Problems/Solutions 

3.  Problem:  We  are  required  to  report  these  changes  threw  CAMS  which  in  turn  in 
sent  to  REMIS.  Do  we  need  to  develop  another  system  and  duplicate  work? 

4.  Problem:  Lack  of  automated  possession  change...  must  be  done  manually. 

5.  Solution:  Data  feed  from  Air  Staff  initiative  system  could  provide  automated 
possession  change. 

Overview 

1.  Parent  Process:  Prepare  &  Submit  107  Request 

2.  Number  of  Children:  0 
Actors 

5.  Wing  P&S  Personnel  - 

6.  QA  Personnel  - 

7.  Maintenance  Personnel  - 

8.  MOC  -  Maintenance  Operations  Center  (Track  Status  of 
Aircraft/Equipment/System  on  a  real  time  basis) 


Process:  Process  107  Request  at  MAJCOM 
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Trigger 

2.  Receipt  of  1 07  Request 
Overview 

3.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

4.  Number  of  Children:  2 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Receive  107  at  MAJCOM 


Description 

2.  AFTO  1 07  submitted  by  Wing  is  received  at  MAJCOM  by  either  through  E-mail 
or  FAX. 

Trigger 

2.  Receipt  of  1 07  Request 
Overview 

2.  Parent  Process:  Process  107  Request  at  MAJCOM 

3.  Number  of  Children:  0 
Actors 

3.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Evaluate  107  Request 


Description 

1 .  Ensure  necessary  information  is  included  to  help  engineers  determine  repair 
disposition 

2.  Validate  Date  Time  Group  on  Official  Message  is  correct 
Overview 

2.  Parent  Process:  Process  107  Request  at  MAJCOM 

3.  Number  of  Children:  3 
Actors 

3.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Validate  107 


Description 

3.  Validate  Date  Time  Group  is  correct 
Overview 

1.  Parent  Process:  Evaluate  107  Request 

2.  Number  of  Children:  0 
Actors 

2.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 
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Process:  Research  107 


Description 

2.  Make  sine  all  necessary  information  is  included  on  the  message  to  help  engineers 
make  proper  repair  disposition 

Overview 

3.  Parent  Process:  Evaluate  107  Request 

4.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Request  Additional  Information  from  Unit 

Description 

2.  If  necessary,  request  additional  information  from  the  field  (e.g.,  pictures  or 
diagrams)  to  help  engineers  formulate  repair  procedures. 

Overview 

2.  Parent  Process:  Evaluate  107  Request 

3.  Number  of  Children:  0 
Actors 

3.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Certify  funding  is  available  for  repair 

Description 

1 .  Ensure  sufficient  DPEM  (Depot  Purchased  Equipment  Maintenance)  is  available 
to  fund  repair. 

Problems/Solutions 

2.  Problem:  TO  00-25-107,  para  6.2  mentions  certification  by  MAJCOM  that  all 
resources  have  been  exhausted.  It  is  assumed  this  certification  also  considers 
available  funding.  Para  6.3,  with  potentially  much  higher  costs,  makes  no  mention 
of  "certification.'' 

3.  Possible  solution:  AFTO  FORM  22  to  TO  0-25-107  to  standardize  these  two 
paragraphs. 

Overview 

2.  Parent  Process:  Evaluate  107  Request 

3.  Number  of  Children:  1 

Actors 

3.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 
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Process:  Cost  estimate  pre-certification 

Description 

1 .  Air  National  Guard  and  AFMC  requires  cost  estimate  from  the  Depot  prior  to 
MAJCOM  Certification  to  verify  if  funds  are  available 

2.  AETC  occasionally  request  cost  estimate  to  determine  available  funding. 
Overview 

2.  Parent  Process:  Certify  funding  is  available  for  repair 

3.  Number  of  Children:  0 
Actors 

2.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Review  Cost  Prohibitive  Estimates 


Description 

3.  Coordinate  with  Air  Staff  for  possible  attrition  action  if  cost  to  repair  exceeds 
economic  limits. 

Trigger 

1.  Extensive  damage  causing  prohibitive  cost 
Overview 

2.  Parent  Process:  Certify  funding  is  available  for  repair 

3.  Number  of  Children:  0 
Actors 

3.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Execute  107  Disposition 


Description 

3.  MAJCOM  MDS/System  Functional  Manager  coordinates  and  sends  request  to 
depot 

Trigger 

1.  Completion  of  MAJCOM  Evaluation 
Overview 

2.  Parent  Process:  Process  107  Request  at  MAJCOM 

3.  Number  of  Children:  1 
Actors 

2.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Forward  107  Certification 
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Description 

2.  MAJCOM  sends  107  Certification  Message  to  depot  with  CC  to  unit 
Overview 

3.  Parent  Process:  Execute  107  Disposition 

4.  Number  of  Children:  0 
Actors 

1 .  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Forward  107  Disapproval 

Description 

2.  Send  disapproval  to  unit  with  CC  to  depot.  Notify  unit  to  accurately  document 
time  taken  for  an  erroneous  possession. 

3.  Note:  May  be  some  differences  on  TO/CC  for  individual  MAJCOMs. 

Overview 

2.  Parent  Process:  Execute  107  Disposition 

3.  Number  of  Children:  0 
Actors 

2.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 


Process:  Process  MAJCOM  Response  at  Wing 

Description 

3.  Disseminate  to  key  players  MAJCOM's  response  to  the  submitted  107. 

Trigger 

1 .  Receipt  of  MAJCOM  Response  or  Request  for  Additional  Information 
Overview 

2.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

3.  Number  of  Children:  2 
Actors 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 

4.  Maintenance  Personnel  - 


Process:  Provide  Additional  Information 


Description 

3.  As  requested,  provide  any  additional  information  to  MAJCOM.  Contact  key 
players  for  help. 

Trigger 

1 .  MAJCOM  Request  for  Additional  Information 
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Overview 

2.  Parent  Process:  Process  MAJCOM  Response  at  Wing 

3.  Number  of  Children:  0 
Actors 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

5.  QA  Personnel  - 


Process:  Review  MAJCOM  Approval/Disapproval 


Description 

3.  Review  the  Approval/Disapproval  decision  from  MAJCOM.  Request  clarification 
if  needed. 

Trigger 

1 .  Receipt  of  MA J COM  Response 

Overview 

2.  Parent  Process:  Process  MAJCOM  Response  at  Wing 

3.  Number  of  Children:  0 
Actors 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 

4.  Maintenance  Personnel  - 

5.  AFETS  -  Ar  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Submit  Msg  to  reflect  Possession  Change 


Description 

2.  If  107  disapproved,  Wing  P&S  submits  AFI 21-103  message  returning  system  to 
appropriate  possession  code  effective  time  of  original  possession  purpose 
identifier  change. 

Trigger 

3.  Receipt  MAJCOM  Response 

Problems/Solutions 

1 .  Problem:  We  are  required  to  report  these  transactions  through  CAMS,  then  it’s 
sent  to  REMIS.  Do  we  need  to  develop  another  system  to  duplicate  our  efforts? 

2.  Problem:  Loss  of  accurate  reporting  status  due  to  slow  1 07  process....need  to 
automate  whole  process. 

3.  Solution:  use  technology  used  for  this  teleconferencing  process  to  upgrade  the 
107  request  process.  The  video  and  audio  links  are  real  time  and  a  formal 
conclusion  can  be  reached  and  printed  from  the  computer  systems  at  the  close  of 
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the  conferencing  session.  Note:  This  may  not  be  a  very  "good"  solution  if  we  must 
rely  on  the  type  of  teleconferencing  capabilities  we  have  seen  today! 

Overview 

4.  Parent  Process:  Process  MAJCOM  Response  at  Wing 

5.  Number  of  Children:  0 
Actors 

2.  Wing  P&S  Personnel  - 

3.  Maintenance  Personnel  - 

4.  MOC  -  Maintenance  Operations  Center  (Track  Status  of 
Aircraft/Equipment/System  on  a  real  time  basis) 


Process:  Process  107  Request  at  Depot 

Description 

2.  Receive  107  request  from  Unit/MAJCOM  and  prepare  repair  disposition. 

Trigger 

3 .  Receipt  of  1 07  Request 
Overview 

1.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

2.  Number  of  Children:  3 
Actors 

4.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 


Process:  Receive  107  Request  at  Depot 

Description 

2.  Receive  1 07  from  unit  via  official  formal  message,  e-mail  or  fax. 
Trigger 

2.  Receipt  of  1 07  Request 
Overview 

3.  Parent  Process:  Process  107  Request  at  Depot 

4.  Number  of  Children:  1 
Actors 

1 .  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 


Process:  Log-in  107 

Description 

4.  Receive  107  from  unit  and  log-in  to  database  system  and/or  manual  system. 

Overview 

2.  Parent  Process:  Receive  107  Request  at  Depot 

3.  Number  of  Children:  0 

Appendix  B 


154 


Actors 

2.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 


Process:  Send  Copy  of  107  to  Engineering 


Description 

3.  A  memo  requesting  repair  disposition,  including  parts  list  plus  any  applicable 
T.O.  figure  and  index,  grounding  or  flying  decision,  and  SOR  (Source  of  repair: 
CFT/DFT/O&I/PDM/DIM,  etc.)  is  attached  to  the  -107  and  sent  to  engineering 
via  e-mail  or  fax. 

Problems/Solutions 

1 .  Problem:  More  information  required  to  determine  extent  of  repair  needed. 

2.  Solution:  Contact  performing  work  center  for  more  info  instead  of  running  it  all 
the  way  back  down  the  chain. 

Overview 

4.  Parent  Process:  Receive  107  Request  at  Depot 

5.  Number  of  Children:  0 
Actors 

2.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 

Process:  Evaluate  and  Make  Disposition  of  107 


Description 

2.  Review  107  and  prepare  repair  disposition.  This  includes  the  type  of  repair,  level 
of  repair,  status  of  aircraft  (grounded,  flyable)  or  equipment/system,  and 
parts/tooling  requirements.  Disposition  is  sent  to  Depot  107  Program  Manager 
(e.g.,  LFPLW  at  WR-ALC)  when  completed. 

Trigger 

3.  Receipt  of  107  from  Depot  107  Program  Mgt  Personnel 
Overview 

1.  Parent  Process:  Process  107  Request  at  Depot 

2.  Number  of  Children:  4 
Actors 

3.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 


Process:  Assign  Priority  to  107 

Description 

2.  Normally,  a  107  request  is  processed  and  worked  in  the  order  received  and  no 
priority  is  assigned. 
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3.  Under  special  circumstances,  a  priority  may  be  assigned  to  the  107  request  and 
influenced  by  importance  of  the  aircrafit/equipment/system  to  the  mission,  input 
from  MAJCOM  POCs. 

Overview 

2.  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

3.  Number  of  Children:  0 
Actors 

3.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Assign  107  to  Engineer 

Description 

1 .  Determine  which  engineer  has  the  expertise  and/or  time  to  work  the  1 07 
Overview 

2.  Parent  Process:  Evaluate  and  Make  Disposition  of  1 07 

3.  Number  of  Children:  0 
Actors 

2.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Log-in  to  Tracking  Database 

Description 

3 .  Log  the  1 07  in  to  the  engineering  database 
Overview 

1 .  Parent  Process:  Evaluate  and  Make  Disposition  of  1 07 

2.  Number  of  Children:  0 
Actors 

2.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Prepare  Disposition 

Description 

2.  Engineer  conducts  the  necessary  research,  analysis,  design  and  coordination  to 
prepare  the  disposition 

Overview 

3.  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

4.  Number  of  Children:  3 
Actors 

1 .  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 
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Process:  Review  107  Request 


Description 

2.  Assigned  engineer  receives  the  1 07  request,  reads  the  request  and  determines  the 
next  action. 

Overview 

2.  Parent  Process:  Prepare  Disposition 

3.  Number  of  Children:  0 
Actors 

2.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 


Process:  Review  Drawings  in  Data  Repository/TOs 

Description 

3.  Detailed  drawings  are  available  in  the  Data  Repository  and/or  TOs  and  are 
reviewed  as  part  of  the  process  of  developing  the  repair  disposition. 

Overview 

1.  Parent  Process:  Prepare  Disposition 

2.  Number  of  Children:  0 
Actors 

2.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

3.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Request  Additional  Info  from  Field 

Description 

3.  Process  Name:  Request  Additional  Information  from  Field 

4.  After  reviewing  the  1 07  request,  additional  information  may  be  requested  from 
the  field  unit  that  submitted  the  request. 

Overview 

3.  Parent  Process:  Prepare  Disposition 

4.  Number  of  Children:  0 
Actors 

1 .  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

2.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Develop  Repair 
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Description 

2.  After  all  of  the  information  is  received  and  reviewed,  a  repair  plan  is  developed 
by  the  engineer  that  details  what  needs  to  be  done  and  which  SOR  will 
accomplish  the  repair. 

Overview 

2.  Parent  Process:  Prepare  Disposition 

3.  Number  of  Children:  0 
Actors 

3.  Depot  Engineering  Personnel  -  Engineering  supervisors,  secretaries,  and 
engineers  at  Depot 

4.  Depot  Supervisor  or  Lead  Engineer  - 

Process:  Approve  Disposition 


Description 

1 .  Supervisory  or  lead  engineer  reviews  the  disposition  for  technical  adequacy. 
Overview 

2.  Parent  Process:  Evaluate  and  Make  Disposition  of  107 

3.  Number  of  Children:  0 
Actors 

2.  Depot  Supervisor  or  Lead  Engineer  - 


Process:  Receive  MAJCOM  Cert/Disapproval 


Description 

3 .  Receive  MAJCOM  Certification  or  Disapproval. 

Trigger 

1 .  Receipt  of  MAJCOM  Certification/Disapproval 

Problems/Solutions 

2.  Problem:  Certain  MAJCOM's,  who  provide  command  certification's/disapprovals 
via  e-mail  only,  do  not  appear  to  have  a  system  to  prevent  duplication  of 
transmissions  between  in-house  personnel.  Sometimes  it  is  not  known  even  if  a 
initial  command  cert  or  disapproval  has  been  forwarded. 

3.  Solution:  Develop  some  sort  of  data  base  or  manual  system  central  point  of 
reference  so  that  all  in-house  MAJCOM  personnel  can  determine  if  a  command 
cert/disapproval  has  been  issued. 

Overview 

2.  Parent  Process:  Process  107  Request  at  Depot 

3.  Number  of  Children:  0 

Actors 

3.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 
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Process:  Execute  Disposition  of  107 


Description 

1 .  Carry-out  the  disposition  of  the  1 07.  This  can  include  field-level  repairs,  depot 
drop-in  maintenance,  depot-level  repair,  satisfactory  as-is,  or  repair  by  contract 
field  team. 

Trigger 

3 .  Receipt  of  Disposition  from  Depot  Engineering  Personnel 
Overview 

2.  Parent  Process:  Process  107  Request  at  Depot 

3.  Number  of  Children:  5 
Actors 

3.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 


Process:  Draft/Send  Repair  Disp  Message  to  Unit 


Description 

1 .  Send  courtesy  copy  of  engineering  repair  disposition  to  unit  and  MAJCOM  via  e- 
mail  or  fax  prior  to  official  message. 

2.  Prepare  and  send  official  formal  message  to  MAJCOM  with  CC  to  unit  stating  the 
disposition  of  the  repair  (type  of  repair,  level  of  repair,  flying  status  (grounded  or 
flying),  and  parts/tooling  required). 

3.  If  MAJCOM  disapproved  107,  formal  message  sent  closing  107  action. 

4.  Preferred  method  of  transmission  is  through  E-Mail 
Overview 

2.  Parent  Process :  Execute  Disposition  of  1 07 

3.  Number  of  Children:  0 
Actors 

3.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 


Process:  Prepare  Costing  &  Pers  Details  for  DFT 

Description 

1 .  Process  Name:  Prepare  Costing  and  Personnel  Details  of  DFT 

2.  Determine  the  cost  of  the  repair,  the  personnel  required,  and  the  number  of  man¬ 
hours  to  complete  the  repair.  This  work  is  accomplished  by  the  Workload/Planner 
and  is  done  when  a  DFT  will  perform  the  repair. 

Trigger 

3.  SOR  Decision  =  DFT 
Overview 

2.  Parent  Process:  Execute  Disposition  of  107 

3.  Number  of  Children:  0 
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Actors 

3.  Depot  Workloader/Planner  - 


Process:  Prepare  206  for  DFT  Deployment 

Description 

1 .  Complete  the  AFLC  Form  206  electronically  and  forward  to  Program/Funds 
Control  Division  (LFC  at  WR-ALC).  The  206  is  a  Temporary  Work  Request  and 
vehicle/document  that  funds  the  applicable  source  of  repair  to  repair  the 
aircraft/equipment/system. 

Trigger 

3 .  SOR  Decision  =  DFT 

Problems/Solutions 

2.  Problem:  Certain  MAJCOM's  do  not  provide  annual/quarterly  funding  to  depot 
budget  offices  causing  delays  in  getting  approval  in  -107's  that  require  non  stock 
listed  parts  to  be  manufactured  or  DFT's  to  be  deployed. 

Overview 

3 .  Parent  Process:  Execute  Disposition  of  1 07 

4.  Number  of  Children:  0 

Actors 

1.  Depot  107  Program  Mgt  Personnel  -  Example:  WR-ALC  (LFPLW) 


Process:  Request  Applicable  SOR 

Description 

3.  Request  the  applicable  source  of  repair  (SOR)  that  will  complete  the  repair.  The 
depot  field  team  (DFT)  can  include  personnel  from  the  Combat  Logistics  Support 
Squadron  (CLSS)  or  from  civilian  personnel. 

4.  Source  of  Repair  (SOR)  definitions  -  Depot  field  team  (DFT),  Contract  field  team 
(CFT),  Organizational  and  Intermediate  (O&I),  Program  Depot  Maintenance 
(PDM),  Drop-In-Maintenance  (DIM),  Aircraft  Damage  Repair  (ADR). 

Overview 

2.  Parent  Process:  Execute  Disposition  of  107 

3.  Number  of  Children:  0 
Actors 

3.  Depot  Workloader/Planner  - 

4.  Depot  Contract  Field  Team  Program  Manage  - 


Process:  Prepare  and  Ship  Tooling 
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Description 

1 .  Based  upon  the  requirements  of  the  repair,  Production  Support  Branch  (e.g., 
LFPSI  at  WR-ALC)  will  assemble  and  ship  required  special  tooling  to  the  unit. 

Overview 

2.  Parent  Process:  Execute  Disposition  of  107 

3.  Number  of  Children:  0 
Actors 

2.  Depot  Workloader/Planner  - 

3.  Depot  Transportation  Personnel  - 

4.  Commercial  Carrier  -  Commercial  transportation  carrier  that  ships  the  tooling  to 
the  unit 


Process:  Deploy  DFT  if  applicable 


Description 

2.  Upon  verification  that  all  parts  and  equipment  are  on-site  at  the  unit,  the  DFT  is 
deployed  via  commercial/military  air  or  POV  to  make  the  repair.  This  process 
only  takes  place  If  DFT  has  been  identified  as  the  repair  source. 

Trigger 

3 .  SOR  Decision  =  DFT 
Overview 

1.  Parent  Process:  Execute  Disposition  of  107 

2.  Number  of  Children:  0 
Actors 

2.  Depot  Field  Team  - 

3.  Depot  Workloader/Planner  - 


Process:  Process  Depot  Response  at  Wing 


Description 

2.  Review  response  from  Depot  and  provide  additional  information,  as  needed. 
Follow  all  instructions  received  from  the  Depot.  Disposition  could  require  any  of 
the  following  actions:  -  Order  parts  and/or  equipment  -  Complete  the  repair 
locally  under  direction  of  Depot  -  Assist  as  needed  in  the  repair  efforts  of  the 
Depot  Field  Team  -  Perform  temporary  fix  and  send  to  Depot  for  repairs  - 
Continue  operation  without  repairs,  at  this  time  -  Permanently  remove  item  from 
service. 

Trigger 

2.  Receipt  of  Depot  Response  or  Request  for  Additional  Information 

Overview 

3.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

4.  Number  of  Children:  3 
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Actors 

1 .  Wing  P&S  Personnel  - 

2.  QA  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  Maintenance  Personnel  - 


Process:  Notify  Work  Center  of  Depot  Response 

Description 

2.  Notify  work  center  of  any  response  received  from  Depot  and  take  appropriate 
action. 

Overview 

5.  Parent  Process:  Process  Depot  Response  at  Wing 

6.  Number  of  Children:  0 
Actors 

3.  Wing  P&S  Personnel  - 

4.  QA  Personnel  - 


Process:  Lose  Possession 


Description 

1 .  If  1 07  approved  for  aircraft,  submit  AFI 21-103  message  losing  possession  to 
depot  -DJ  possession  purpose  identifier  if  you  are  waiting  for  a  team  to  arrive, 
then  change  it  to  DM  possession  purpose  identifier  when  the  team  arrives. 

Overview 

2.  Parent  Process:  Process  Depot  Response  at  Wing 

3.  Number  of  Children:  0 


Process:  Provide  Additional  Information 


Description 

3.  Provide  any  additional  information  requested  by  the  Depot.  Contact  appropriate 
work  center  for  additional  information  and  submit  information  to  Depot. 

Trigger 

2.  Request  for  Additional  Information 
Overview 

3.  Parent  Process:  Process  Depot  Response  at  Wing 

4.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  QA  Personnel  - 
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3.  Wing  P&S  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Follow  Depot  Instructions 


Description 

2.  Follow  all  instructions  received  from  the  Depot  pertaining  to  the  repair  or 
continued  use  of  the  equipment. 

Trigger 

2.  Receipt  of  Depot  Response 
Overview 

2.  Parent  Process:  Process  Depot  Response  at  Wing 

3.  Number  of  Children:  1 
Actors 

3.  Maintenance  Personnel  - 

4.  Wing  P&S  Personnel  - 

5.  QA  Personnel  - 


Process:  Order  Parts  and/or  Equipment  as  Required 

Description 

1 .  Research  and  order  any  parts  and/or  equipment  required  by  the  Depot  or  work 
center  to  accomplish  repair,  if  not  already  on  hand.  Parts  may  be  issued  or  be 
backordered  and  require  lots  of  waiting. 

Overview 

2.  Parent  Process:  Follow  Depot  Instructions 

3.  Number  of  Children:  4 
Actors 

3.  Maintenance  Personnel  - 


Process:  Research  Required  Parts  and  Equipment 


Description 

3.  Find  Stock  or  Part  Numbers  for  the  Parts  or  Equipment  by  using  TO's,  FedLog, 
and/or  calling  Depot  for  information. 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 
Actors 

3.  Maintenance  Personnel  - 
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Process:  Prepare  &  Submit  Order  for  Parts  &  Equip 

Description 

2.  Prepare  necessary  documents  to  order  the  required  parts  and/or  equipment  and 
submit  it  to  appropriate  agencies. 

3.  Note:  Depot  may  or  may  not  provide  parts  themselves  depending  on  funding  and 
parts  availability  (e.g.,  depot  may  need  to  manufacture  parts). 

Overview 

3.  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

4.  Number  of  Children:  0 
Actors 

1 .  Maintenance  Personnel  - 

2.  Supply  Personnel  - 


Process:  Receive  Ordered  Parts  and  Equipment 

Description 

3.  Receive  the  Parts/Equipment  from  Base  Supply  stock,  from  other  bases,  from  the 
manufacturer  or  from  the  Depot. 

Overview 

2.  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

3.  Number  of  Children:  0 
Actors 

2.  Maintenance  Personnel  - 

3 .  Supply  Personnel  - 


Process:  Follow  up  on  Backordered  Parts/  Equip 

Description 

3.  If  the  Parts  or  equipment  are  not  available,  then  Supply  will  go  to  other  bases,  to 
the  Depot,  or  to  the  manufacturer  to  retrieve  them.  The  owning  work  center  will 
keep  track  of  the  supplies  that  have  not  been  issued  by  using  a  supply  document 
number. 

Overview 

1 .  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

2.  Number  of  Children:  0 

Actors 

2.  Maintenance  Personnel  - 

3.  Maintenance  Personnel  from  other  bases  -  Maintenance  personnel  that  maintain 
like  acft/equip/systems 

4.  Supply  Personnel  - 
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Process:  Notify  Depot  of  Parts/Equipment  Receipt 


Description 

2.  Notify  Depot  when  all  parts/hardware  and  applicable  tooling/equipment  are  on 
site. 

Overview 

2.  Parent  Process:  Order  Parts  and/or  Equipment  as  Required 

3.  Number  of  Children:  0 
Actors 

3.  Maintenance  Personnel  - 

4.  QA  Personnel  - 

5.  Wing  P&S  Personnel  - 

6.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Repair  Item/Return  to  Operation 


Description 

1 .  Repair  aircraft/equipment/system  as  directed  and/or  return  to  operation. 
Overview 

5.  Parent  Process:  Follow  Depot  Instructions 

6.  Number  of  Children:  4 
Actors 

2.  Maintenance  Personnel  - 

3.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

4.  QA  Personnel  - 


Process:  Complete  Temp  Fix  &  Send  Item  to  Depot 


Description 

3.  Follow  all  directions  from  Depot  to  accomplish  a  temporary  fix  of  the  problem. 
Send  aircraft/equipment/system  to  Depot  for  repair  as  required  by  Depot 
schedule. 

Overview 

1.  Parent  Process:  Repair  Item/Retum  to  Operation 

2.  Number  of  Children:  0 
Actors 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

5.  QA  Personnel  - 
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Process:  Coord  Depot  Field  Team  Repair  Efforts 


Description 

2.  Process  Name:  Coordinate  Depot  Field  Team  Repair  Efforts 

3.  After  the  initial  meeting,  coordinate  with  Depot,  work  center  and  any  other  shops 
required  on  when,  where,  and  how  the  repair  by  the  Depot  Field  Team  will  be 
accomplished. 

Overview 

2.  Parent  Process:  Repair  Item/Retum  to  Operation 

3.  Number  of  Children:  0 
Actors 

3.  Wing  P&S  Personnel  - 

4.  QA  Personnel  - 

5.  Maintenance  Personnel  - 

6.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

7.  Depot  Field  Team  - 


Process:  Follow  Depot  Guidance  for  Local  Repair 


Description 

1 .  Follow  the  guidance  and  repair  action  received  from  Depot  to  accomplish  any 
O&I  level  repair  of  the  aircraft/equipment/system. 

Overview 

5.  Parent  Process:  Repair  Item/Retum  to  Operation 

6.  Number  of  Children:  0 
Actors 

2.  Maintenance  Personnel  - 

3.  QA  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 


Process:  Continue  Operation  of  Item 


Description 

2.  Follow  all  guidance  received  from  Depot  for  continued  operation  of  the 
'Satisfactory  As-Is'  aircraft/equipment/system. 

Overview 

3 .  Parent  Process:  Repair  Item/Retum  to  Operation 

4.  Number  of  Children:  0 
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Actors 

1 .  Wing  P&S  Personnel  - 

2.  Maintenance  Personnel  - 


Process:  Permanently  Remove  from  Service 


Description 

4.  If  determination  is  made  that  it  is  not  economically  feasible  to  repair,  permanently 
remove  aircraft/equipment/system  from  service. 

Overview 

2.  Parent  Process:  Repair  Item/Return  to  Operation 

3.  Number  of  Children:  0 
Actors 

3.  Air  Staff  - 

4.  MAJCOM  Personnel  -  Mission  Design  Series  (MDS)/System  Functional  Manager 

5.  Maintenance  Personnel  - 

6.  Wing  P&S  Personnel  -  , 


Process:  Prepare  &  Submit  Supp  107  As  Reqd 


Description 

1 .  If  additional  discrepancy  discovered  during  repair,  prepare  and  submit 
supplemental  (new)  107  as  previously  defined. 

Trigger 

3.  Identification  of  additional  discrepancies  during  repair  process 

Overview 

2.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

3.  Number  of  Children:  0 
Actors 

3.  Maintenance  Personnel  - 

4.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

5.  QA  Personnel  - 

6.  Wing  P&S  Personnel  - 


Process:  Verify  107  Completion 


Description 

1 .  Ensure  that  all  maintenance  repair  actions  have  been  completed  and  that  all 
documentation  is  signed. 

Trigger 

2.  Repair  action  completed 

Appendix  B 


167 


Overview 

3.  Parent  Process:  Process  AFTO  107  Requests  for  Tech  Assist 

4.  Number  of  Children:  4 
Actors 

3.  QA  Personnel  - 

4.  Maintenance  Personnel  - 

5.  AFETS  -  Air  Force  Engineering  Technical  Services  (by  aircraft  Major  Design 
Series) 

6.  Wing  P&S  Personnel  - 


Process:  Inspect  Repair  by  QA 

Description 

1 .  QA  inspector  checks  repair  work  to  ensure  that  all  required  work/repair  has  been 
completed  in  a  satisfactory  manner  and  all  required  documentation  is  completed. 
Arrive  at  an  acceptable  solution  if  repair  is  not  acceptable. 

Problems/Solutions 

3.  Problem:  There  is  no  step  for  QA  to  inspect  repair  before  the  depot  team  is 
released  by  the  owning  unit. 

4.  Solution:  Add  QA  Inspector  block  to  maintenance  completion  form  used  to  'sell' 
aircraft  back  to  owning  work  center  alongside  the  Repair  Technician's  signature. 
This  will  help  resolve  the  problem  of  Wing  P&S  not  being  notified  by  QA  upon 
completion. 

Overview 

2.  Parent  Process:  Verify  107  Completion 

3.  Number  of  Children:  0 
Actors 

3.  QA  Personnel - 


Process:  Review  Repair  Documentation 


Description 

1 .  Review  appropriate  repair  documentation.  Maintain  copy  for  Base  Historical 
records. 

Overview 

3.  Parent  Process:  Verify  107  Completion 

4.  Number  of  Children:  0 
Actors 

2.  QA  Personnel  - 

3.  Wing  P&S  Personnel  - 
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Process:  Notify  Wing  P&S  of  Completion 

Description 

3 .  Q A  should  notify  Wing  P&S  or  other  appropriate  1 07  POC  of  completion  of  1 07 
repair  so  they  can  gain  possession  of  the  aircraft. 

Problems/Solutions 

1 .  Problem:  Many  times  the  team  is  on  its  way  home  before  Wing  is  notified  the 
process  is  completed.  This  causes  a  laps  in  time  of  reporting  possession  changes 
to  HQ  resulting  in  erroneous  information  at  that  level. 

2.  Solution:  QA  notify  Wing  P&S  when  the  process  is  completed 

Overview 

3.  Parent  Process:  Verify  107  Completion 

4.  Number  of  Children:  0 


Process:  Notify  MAJCOM/Depot  of  Completion 


Description 

2.  Note:  This  is  currently  not  being  done  by  the  Wing  with  regularity. 

3.  Send  final  message  to  MAJCOM/Depot  of  completion  of  the  work  outlined  in  the 
107. 

Overview 

3.  Parent  Process:  Verify  107  Completion 

4.  Number  of  Children:  0 
Actors 

1.  Q A  Personnel - 

2.  Wing  P&S  Personnel  - 


Process:  Submit  Msg  to  reflect  Possession  Change 


Description 

4.  Wing  P&S  submits  AFI 21-103  message  to  return  aircraft/equipment/system  to 
owning  unit  possession. 

Overview 

2.  Parent  Process:  Verify  107  Completion 

3.  Number  of  Children:  0 
Actors 

3.  Wing  P&S  Personnel  - 

4.  MOC  -  Maintenance  Operations  Center  (Track  Status  of 
Aircraft/Equipment/System  on  a  real  time  basis) 

5.  Maintenance  Personnel  - 

6.  QA  Personnel  - 


Appendix  B 


169 


AFTO  107  Problem/Solution  Action  List  (Categorizer) 


1.  Air  Staff  initiate  and  fund  state  of  the  art  real-time  AFTO  107  system 

2.  Establish  a  Worldwide  107  conference 

Can't  happen  at  the  F-15  maintainers  conference 

Air  Staff  will  chair  this  conference 

Who  will  chair  such  a  conference?  I  suggest  Jim  McManus! 

Could  be  rotated  by  MAJCOM's  on  chairing 

3.  Evaluate  current  B-l  web-based  system  and  see  if  it  can  be  adapted  to  other 
systems. 

Please  send  e-mail  to  Steven  Kidd  as  to  who  is  responsible  for  this  system  and  the 
URL  so  he  can  access  the  system. 

4.  Develop  a  system  to  promote  the  use  of  cross-tells  to  share  repair  ideas 

5.  Establish  one  central  point  of  contact  with  subject  matter  expertise  for  the 
particular  system  at  the  Wing 

6.  Standardize  the  single  point  of  contact  via  the  TO  or  MAJCOM  supplements 

7.  Recommend  changes  to  TO  107  in  regard  to  107  content  required 

8.  Add  additional  detail  to  the  actual  TO  describing  the  specific  format  for  each 
paragraph  that  must  be  submitted 

9.  Develop  web-based  forms  for  submittal  of  107  requests 
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Meeting  2  Session 

Evaluation  -  Survey  Results 

Process  Modeler  Tool  Ease  of  Use 

1.  Learning  to  operate  the  Process  Modeler  tool  was  easy  for  me. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 

Choices 

Count 

SA(5) 

3 

A(4) 

8 

N(3) 

1 

D(2) 

0 

SD(1) 

0 

Statistics 

Mean 

A(4.17) 

STD 

0.58 

2.  I  found  it  easy  to  get  the  Process  Modeler  tool  to  do  what  I  wanted  it  to  do. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 

Choices 

Count 

SA(5) 

5 

A  (4) 

6 

N(3) 

1 

D(2) 

0 

SD(1) 

OS 

Statistics 

Mean 

A(4.33) 

STD 

0.65 

3.  My  interactions  with  the  Process  Modeler  tool  were  clear  and  understandable, 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 

Choices 

Count 

SA(5) 

6 

A  (4) 

5 

N(3) 

1 
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D(2) 

SD(1) 


0 
0 

Statistics 

Mean  A(4.42) 

STD  0.67 


4.  I  found  the  Process  Modeler  tool  flexible  to  interact  with. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 

m 

D(2) 

SD(1) 


Count 

5 

5 

2 

0 

0 


Statistics 

Mean  A(4.25) 

STD  0.75 


5.  It  was  easy  for  me  to  become  skillful  at  using  the  Process  Modeler  tool. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices  Count 

SA(5)  4 

A  (4)  7 

m  i 

D(2)  0 

SD(1)  0 

Statistics 

Mean  A(4.25) 

STD  0.62 

6.  Interacting  with  the  Process  Modeler  tool  did  not  require  a  lot  of  mental  effort. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices  Count 

SA(5)  4 

A(4)  8 
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m 

D(2) 

SD(1) 

Statistics 

Mean 

STD 


A(4.33) 

0.49 


7.  I  found  the  Process  Modeler  tool  easy  to  use. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 


Count 


SA(5) 

A  (4) 

N(3) 

D(2) 

SD(1) 

Statistics 

Mean 

STD 


A(4.17) 

0.58 


8.  If  you  participated  in  the  earlier  meeting,  did  the  changes  in  the  Process  Modeler 
tool  improve  its  ease  of  use? 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 

m 

D(2) 

SD(1) 

Statistics 

Mean 

STD 


Count 

3 

2 

6 

0 

0 


A(3.73) 

0.90 


9.  What  changes  would  you  recommend  to  improve  the  ease  of  use  of  the  Process 
Modeler  tool?  (Open-Ended) 

l.none 
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2.  My  computer  did  not  update  all  of  the  information,  I  had  to  use  another 
members  monitor  to  participate  in  the  discussion. 

3.  NO  real  changes,  I  found  it  easy  to  use. 

4.  Add  mini  pop-up  help  notes  that  appear  when  you  place  the  cursor  over  a  tool 
bar  icon 

-  Add  same  for  showing  the  entire  description  of  a  node  when  the  cursor  is  placed 
over  it,  vice  having  to  scroll  across 

-  Add  the  ability  to  drag  nodes  in  the  process  tree 

-  Add  a  graphical  depiction  of  the  process/decision  tree  and  the  ability  to  click  on 
it  to  jump  to  that  node  of  the  process 


overall  Assessment  of  the  Process  Modeler  Tool 

10.  What  did  you  like  least  about  the  Process  Modeler  tool?  (Open-Ended) 

1 .  The  loss  of  capability  when  network  went  down 

11.  What  did  you  like  best  about  the  Process  Modeler  tool?  (Open-Ended) 

1 .  It's  ease  of  use 

2.  It  is  easy  to  use  and  great  to  be  able  to  see  others  comments  at  the  same  time, 

3.  ease  of  use 

12.  If  you  could  change  only  one  thing  in  the  Process  Modeler  tool,  what  would  you 
tell  the  designers  to  change?  (Open-Ended) 

1 .  Nothing 

2.  Nothing 


AFTO  107  Process  Model  Quality 


13.  The  overall  quality  of  the  AFTO  107  process  model  developed  was: 

Excellent  (E),  Very  Good  (VG),  Good  (G),  Fair  (F),  Poor  (P) 

Choices  Count 

E(5)  3 

VG(4)  8 

G(3)  1 

F(2)  0 

P(l)  0 

Statistics 

Mean  VG(4.17) 
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STD 


0.58 


14.  The  overall  quality  of  the  recommended  improvements  to  the  AFTO  107  process 
identified  were: 

Excellent  (E),  Very  Good  (VG),  Good  (G),  Fair  (F),  Poor  (P) 

Choices  Count 

E(5)  4 

VG(4)  5 

G(3)  3 

F(2)  0 

P(l)  0 

Statistics 

Mean  VG(4.08) 

STD  0. 79 

15.  Personnel  involved  in  the  107  Process  could  easily  understand  the  meaning  of  the 
process  model  developed  with  a  minimum  amount  of  explanation. 

SA-Strongly  Agree  A- Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

Count 

SA(5) 

6 

A  (4) 

6 

m 

0 

D(2) 

0 

SD(1) 

0 

Statistics 

Total 

54 

Mean 

SA(4.50) 

STD 

0.52 

The  process  model  developed  was: 

Completely  Correct  (CC),  Mostly  Correct  (MC),  Average  (A),  Somewhat  Incorrect  (SI),  Mostly 

Incorrect  (MI) 

Choices 

Count 

CC(5) 

2 

MC(4) 

10 

A  (3) 

0 

SI(2) 

0 

MI(1) 

0 

Statistics 
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Mean 

STD 


MC(4. 1 7) 
0.39 


17.  The  process  model  developed  was: 

Very  Complete  (VC),  Mostly  Complete  (MC),  Average  (A),  Somewhat  Incomplete  (SI),  Very 


Incomplete  (VI) 

Choices 

Count 

'VC  (5) 

3 

MC(4) 

8 

A  (3) 

1 

SI(2) 

0 

VI(1) 

0 

Statistics 

Mean 

MC(4.17) 

STD 

0.58 

18.  The  process  descriptions  developed  were: 

Very  Clear  (VC),  Mostly  Clear  (MC),  Average  (A),  Somewhat  Vague  (SV),  Very  Vague  (VV) 


Choices 

VC(5) 

MC(4) 

A  (3) 

SV(2) 

W(l) 


Count 

3 

9 

0 

0 

0 


Statistics 

Mean  MC(4.25) 

STD  0.45 


19.  How  satisfied  were  you  with  the  final  AFTO  107  process  model? 

Very  Satisfied  (VS),  Mostly  Satisfied  (MS),  Average  (A),  Somewhat  Unsatisfied  (SU),  Very 
Unsatisfied  (VU) 

Choices  Count 

VS(5)  4 

MS(4)  8 

A(3)  0 

SU(2)  0 

VU(1)  0 

Statistics 

Mean  MS(4.33) 

STD  0.49 
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20.  How  satisfied  were  you  with  the  recommended  AFTO  107  process  improvements? 

Very  Satisfied  (VS),  Mostly  Satisfied  (MS),  Average  (A),  Somewhat  Unsatisfied  (SU),  Very 


Unsatisfied  (VU) 

Choices 

Count 

VS(5) 

6 

MS(4) 

4 

A  (3) 

2 

SU(2) 

0 

VU(1) 

0 

Statistics 

Mean 

MS(4.33) 

STD 

0.78 

Distributed  Meeting  Assessment 


21 .  Having  representatives  participate  from  both  locations  improved  the  quality  of  the 
AFTO  107  process  model. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices  Count 

SA(5)  12 

A  (4)  0 

N(3)  0 

D(2)  0 

SD(1)  0 

Statistics 

Mean  SA(5.00) 

STD  0.00 

22.  Having  representatives  participate  from  both  locations  improved  the  quality  of 
the  recommended  AFTO  107  process  improvements. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

SA(5) 

A  (4) 
N(3) 
D(2) 
SD(1) 


Count 

11 

1 

0 

0 

0 
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Statistics 

Mean 

STD 


SA(4.92) 

0.29 


23.  Representatives  from  both  meeting  locations  participated  equally. 
SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices 

Count 

SA(5) 

6 

A(4) 

6 

m 

0 

D(2) 

0 

SD(1) 

0 

Statistics 

Mean 

SA(4.50) 

STD 

0.52 

Working  with  other  meeting  participants  at  my  location  was: 

Very  Easy  (VE),  Easy  (E),  Average  (A),  Difficult  (D),  Very  Difficult  (VD) 

Choices 

Count 

VE(5) 

7 

E(4) 

4 

A(3) 

1 

D(2) 

0 

VD(1) 

0 

Statistics 

Mean 

VE(4.50) 

STD 

0.67 

25.  Working  with  meeting  participants  at  the  other  location  was: 

Very  Easy  (VE),  Easy  (E),  Average  (A),  Difficult  (D),  Very  Difficult  (VD) 


Choices  Count 


VE(5)  4 

E(4)  2 

A(3)  4 

D(2)  1 

VD(1)  1 


Statistics 
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Mean 

STD 


E(3.58) 

1.31 


26.  My  meeting  location  was: 

[  9  ]  Mountain  Home  AFB 

[  3  ]  Warner  Robins  ALC 

Overall  Meeting  Approach 

27.  Using  this  approach  to  define/improve  the  AFTO  107  process  enabled  me  to 
accomplish  this  task  quickly. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices  Count 

SA(5)  5 

A  (4)  5 

N(3)  2 

D(2)  0 

SD(1)  0 

Statistics 

Mean  A  (4. 2  5) 

STD  0.75 

28.  I  spent  my  time  efficiently  describing  the  AFTO  107  process. 
SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 


Choices  Count 

SA(5)  5 

A  (4)  5 

N(3)  2 

D(2)  0 

SD(1)  0 

Statistics 

Mean  A  (4. 25) 

STD  0.75 

29.  The  meeting  approach  allowed  me  to  everything  I  needed  to  do  to 
define/improve  the  AFTO  107  process. 

SA-Strongly  Agree  A-Agree  N-Neutral  D-Disagree  SD-Strongly  Disagree 
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Choices  Count 

SA(5)  5 

A(4)  6 

N(3)  1 

D(2)  0 

SD(1)  0 

Statistics 

Mean  A(4.33) 

STD  0.65 

30.  How  could  the  approach  followed  in  the  meeting  to  define/improve  the  AFTO 
107  process  be  improved?  (Open-Ended) 

1.  Better  LAN  connectivity 

2.  Improve  connectivity  between  bases,  i.e.  loss  of  video  and  lack  of  audio  quality 

3.  The  only  problem  was  losing  the  internet  but  other  than  that  it  is  a  great 
approach 

4.  Get  all  the  MAJCOMS  involved. 

5.  The  video  conferencing  link  we  had  with  Robins  was  not  all  that  it  should  have 
been 

to  facilitate  a  good  conference.  The  Internet  link  at  Robins  did  not  allow  us 
constant 

access  to  them.  The  Internet  at  Robins  kept  dumping  them  -  forcing  telephone 
speakerphone  discussions  that  did  not  allow  us  good  communications.  The 
software 

was  excellent,  but  the  connection  to  Robins  was  weak. 

3 1 .  How  satisfied  were  you  with  the  overall  meeting  approach? 

Very  Satisfied  (VS),  Mostly  Satisfied  (MS),  Average  (A),  Somewhat  Unsatisfied  (SU),  Very 
Unsatisfied  (VU) 

Choices 
VS(5) 

MS (4) 

A  (3) 

SU(2) 

VUO) 

Statistics 

Mean  MS (4. 25) 

STD  0.62 

32.  How  satisfied  were  you  with  the  overall  meeting  outcome? 
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4 

7 

1 

0 

0 
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Very  Satisfied  (VS),  Mostly  Satisfied  (MS),  Average  (A),  SomewhatUnsatisfied  (SU),  Very 
Unsatisfied  (VU) 


Choices 
VS(5) 
MS (4) 

A  (3) 
SU(2) 

VU(1) 


Count 

2 

9 

1 

0 

0 


Statistics 

Mean  MS(4.08) 

STD  0.51 


Demographics 

33.  How  many  years  have  you  been  working  for  the  military  (combined  active  duty 
and  civilian  time)?  Assign  a  number. 


Value 

12 

13 

15 

16 
18 
20 
22 
23 
26 
32 


Count 

1 

1 

1 

1 

1 

2 

2 

1 

1 

1 


Statistics 

Mean  19.92 

STD  5.68 


34.  How  many  years  have  you  been  working  with  the  AFTO  107  Process?  Assign  a 
number. 


Spread  Value 
2 

3 

4 

5 
11 
12 


Count 

3 

1 

1 

1 

2 

2 
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15 

23 


1 

1 


Statistics 

Mean  8.50 

STD  6.60 

35.  How  often  do  you  use  a  computer? 

[11  ]  Several  times  each  day 

[  0  ]  Once  a  day 

[  1  ]  Several  times  each  week 

[  0  ]  Once  a  week 

[  0  ]  Rarely 

36.  How  would  you  rate  your  expertise  with  use  of  Internet  Browsers? 

Excellent  (E),  Very  Good  (VG),  Good  (G),  Fair  (F),  Poor  (P) 

Choices  Count 

E(5)  3 

VG(4)  5 

G(3)  3 

F(2)  1 

■  m  0 

Statistics 

Mean  VG(3.83) 

STD  0.94 

37.  Before  this  meeting,  how  many  times  had  you  used  GroupSystems? 

[  1  ]  Many  times 

[  3  ]  2  -3  times 

[  2  ]  1  time 

[  6  ]  Never 

38.  Before  this  meeting,  how  many  times  had  you  used  the  Process  Modeler  tool? 

[  0  ]  Many  times 

[  0  ]  2  -3  times 

[  4  ]  1  time 

[  8  ]  Never 

39.  Before  this  meeting,  how  many  times  had  you  developed  a  process,  activity,  or 
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similar  type  model? 

[  0  ]  Many  times 

[  2  ]  2  -3  times 

[  4  ]  1  time 

[  6  ]  Never 
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Meeting  3  Output 

AFTO  107  Problem/Solution  Action  List 


1.  Air  Staff  initiate  and  fund  state  of  the  art  real-time  AFTO  107  system 

2.  Establish  a  Worldwide  107  conference 

Can't  happen  at  the  F-15  maintainers  conference  {1/13/99, 12:58  PM} 

Air  Staff  will  chair  this  conference  { 1 1/6/98, 1 1 :08  AM} 

Who  will  chair  such  a  conference?  I  suggest  Jim  McManus!  { 1 1/6/98, 1 1 :09  AM} 
Could  be  rotated  by  MAJCOM's  on  chairing  { 1 1/6/98, 1 1 :54  AM} 

3.  Evaluate  current  B-l  web-based  system  and  see  if  it  can  be  adapted  to  other 
systems. 

Please  send  e-mail  to  Steven  Kidd  as  to  who  is  responsible  for  this  system  and  the 
URL  so  he  can  access  the  system.  { 1 1/6/98, 11:18  AM} 

4.  Develop  a  system  to  promote  the  use  of  cross-tells  to  share  repair  ideas 

5.  Establish  one  central  point  of  contact  with  subject  matter  expertise  for  the 
particular  system  at  the  Wing 

6.  Standardize  the  single  point  of  contact  via  the  TO  or  MAJCOM  supplements 

7.  Recommend  changes  to  TO  107  in  regard  to  107  content  required 

8.  Add  additional  detail  to  the  actual  TO  describing  the  specific  format  for  each 
paragraph  that  must  be  submitted 

9.  Develop  web-based  forms  for  submittal  of  107  requests 

10.  Develop  a  data  base  to  view  previous  107  problems  and  solutions 

Parking  Lot  (General  Comment) 

1.  Was  briefed  at  last  base  communications  update  meeting  that  all  message  traffic 
will  be  via  e-mail  by  end  of  1999  and  that  Sarah  Lite  message  format  will  be 
discontinued....this  will  force  a  change  to  the  standard  reporting  method/format  for 
all  AFTO  107s...could  be  opportunity  to  get  this  proposal  a  standard  way  of 
submittal  of  AFTO  107s. 
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Vote  on  Importance  of  AFTO  107  Problem/Solution  Action  List 

Items 


Participant  Instructions 

Please  assign  a  level  of  importance  to  each  of  the  ten  items  in  the  list.  A  10  would 
indicate  very  important,  a  1  would  indicate  no  importance.  When  you  have 
completed  your  vote,  click  on  the  "Ballot  Box"  button  to  submit  your  vote. 
Voting  Results 

10-Point  Scale  (Allow  bypass) 

Number  of  ballot  items:  10 

Total  number  of  voters  (N):  8  (7  voted,  1  abstained) 


Mean 

9.57 

8.71 

8.29 

8.00 

7.86 

7.86 

7.86 

7.71 
7.43 

6.57 


1.  Establish  one  central  point  of  contact  with  subject  matter  expertise  for 
the  particular  system  at  the  Wing 

2.  Standardize  the  single  point  of  contact  via  the  TO  or  MAJCOM 
supplements 

3.  Air  Staff  initiate  and  fund  state  of  the  art  real-time  AFTO  107  system 

4.  Develop  a  system  to  promote  the  use  of  cross-tells  to  share  repair  ideas 

5.  Develop  web-based  forms  for  submittal  of  107  requests 

6.  Recommend  changes  to  TO  107  in  regard  to  107  content  required 

7.  Add  additional  detail  to  the  actual  TO  describing  the  specific  format  for 
each  paragraph  that  must  be  submitted 

8.  Develop  a  data  base  to  view  previous  107  problems  and  solutions 

9.  Establish  a  Worldwide  107  conference 

10.  Evaluate  current  B-l  web-based  system  and  see  if  it  can  be  adapted  to 
other  systems. 


Number  of  Votes  in  Each  Rating 

10  987654321 


1 .  Establish  one  central  POC  5 

2.  Standardize  single  POC  4 

3.  Air  Staff  fund  real-time  sys  2 

4.  Develop  sys  to  promote  crosstell  2 

5.  Develop  web-based  forms  0 

6.  Recommend  TO  changes  2 

7.  Add  detail  on  specific  form  2 

8.  Develop  a  107  database  2 

9.  Establish  WW  107  conference  1 

10.  Evaluate  B-l  web  system  0 


1  1 
0  1 
2  1 
1  1 

2  3 
0  2 
2  0 
1  0 

3  1 
1  2 


0  0  0  0  0 
110  0  0 
0  2  0  0  0 
1  2  0  0  0 
110  0  0 
1  2  0  0  0 
110  10 
2  110  0 
0  0  10  0 
1  2  0  0  0 


0  0 
0  0 
0  0 
0  0 
0  0 
0  0 
0  0 
0  0 
1  0 
1  0 


_ Total _ STD _ n 

1.  Establish  one  central  POC  67  0.79  7 
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2.  Standardize  single  POC 

61 

1.70 

7 

3.  Air  Staff  fund  real-time  sys 

58 

1.70 

7 

4.  Develop  sys  to  promote  crosstells 

56 

1.73 

7 

5.  Develop  web-based  forms 

55 

1.07 

7 

6.  Recommend  TO  changes 

55 

1.68 

7 

7.  Add  detail  on  specific  form 

55 

2.27 

7 

8.  Develop  a  107  database 

54 

1.98 

7 

9.  Establish  WW  107  conference 

52 

2.88 

7 

10.  Evaluate  B-l  web  system 

46 

2.30 

7 

Vote  on  Feasibility  of  AFTO  107 
Items 

Problem/Solution  Action  List 

Participant  Instructions 

Please  assign  a  level  of  feasibility  to 

each  of  the  ten  items  in  the  list  indicating 

how  likely  you  feel  the  item  would  be  implemented.  A  10  would  indicate  very 
likely  to  be  implemented,  a  1  would  indicate  no  chance  of  being  implemented. 
When  you  have  completed  your  vote,  click  on  the  "Ballot  Box"  button  to  submit 
your  vote. 

Voting  Results 

1 0-Point  Scale  (Allow  bypass) 

Number  of  ballot  items:  10 
Total  number  of  voters  (N):  5 


Mean 

9.20  1 .  Establish  one  central  point  of  contact  with  subject  matter  expertise  for 
the  particular  system  at  the  Wing 

8.60  2.  Standardize  the  single  point  of  contact  via  the  TO  or  MAJCOM 
supplements 

8.40  3.  Add  additional  detail  to  the  actual  TO  describing  the  specific  format  for 

each  paragraph  that  must  be  submitted 

8.40  4.  Develop  a  system  to  promote  the  use  of  cross-tells  to  share  repair  ideas 

8.20  5.  Recommend  changes  to  TO  107  in  regard  to  107  content  required 

8.00  6.  Develop  web-based  forms  for  submittal  of  1 07  requests 

8.00  7.  Develop  a  data  base  to  view  previous  107  problems  and  solutions 

7.80  8.  Evaluate  current  B-l  web-based  system  and  see  if  it  can  be  adapted  to 

other  systems. 

7.40  9.  Establish  a  Worldwide  107  conference 

6.60  1 0.  Air  Staff  initiate  and  fund  state  of  the  art  real-time  AFTO  1 07  system 

Number  of  Votes  in  Each  Rating 

_  10  987654321 

Appendix  C 


187 


1 .  Establish  one  central  POC 

2 

2  1 

0 

0 

0 

0 

0 

0 

0 

2.  Standardize  single  POC 

2 

1  1 

0 

1 

0 

0 

0 

0 

0 

3.  Add  detail  on  specific  form 

2 

0  1 

2 

0 

0 

0 

0 

0 

0 

4.  Develop  sys  to  promote  crosstel!3 

0  0 

1 

0 

1 

0 

0 

0 

0 

5.  Recommend  TO  changes 

2 

0  1 

1 

1 

0 

0 

0 

0 

0 

6.  Develop  web-based  forms 

1 

1  2 

0 

0 

1 

0 

0 

0 

0 

7.  Develop  a  107  database 

2 

1  0 

1 

0 

0 

1 

0 

0 

0 

8.  Evaluate  B-l  web  system 

2 

1  1 

0 

0 

0 

0 

0 

1 

0 

9.  Establish  WW  107  conference 

1 

1  2 

0 

0 

0 

0 

0 

1 

0 

10.  Air  Staff  fund  real-time  sys 

1 

1  1 

0 

0 

0 

1 

0 

1 

0 

Total 

STD 

n 

1.  Establish  one  central  POC 

46 

0.84 

5 

2.  Standardize  single  POC 

43 

1.67 

5 

3.  Add  detail  on  specific  form 

42 

1.52 

5 

4.  Develop  sys  to  promote  crosstells 

42 

2.30 

5 

5.  Recommend  TO  changes 

41 

1.79 

5 

6.  Develop  web-based  forms 

40 

1.87 

5 

7.  Develop  a  107  database 

40 

2.55 

5 

8.  Evaluate  B-l  web  system 

39 

3.35 

5 

9.  Establish  WW  107  conference 

37 

3.13 

5 

10.  Air  Staff  fund  real-time  sys 

33 

3.44 

5 

Ballot  Items  in  Original  Order 

1.  Air  Staff  initiate  and  fund  state  of  the  art  real-time  AFTO  107  system 

2.  Establish  a  Worldwide  107  conference 

3.  Evaluate  current  B-l  web-based  system  and  see  if  it  can  be  adapted  to  other 
systems. 

4.  Develop  a  system  to  promote  the  use  of  cross-tells  to  share  repair  ideas 

5.  Establish  one  central  point  of  contact  with  subject  matter  expertise  for  the 
particular  system  at  the  Wing 

6.  Standardize  the  single  point  of  contact  via  the  TO  or  MAJCOM  supplements 

7.  Recommend  changes  to  TO  107  in  regard  to  107  content  required 

8.  Add  additional  detail  to  the  actual  TO  describing  the  specific  format  for  each 
paragraph  that  must  be  submitted 

9.  Develop  web-based  forms  for  submittal  of  107  requests 

10.  Develop  a  data  base  to  view  previous  107  problems  and  solutions 
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